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ABSTRACT 


Maintaining  an  information  advantage  for  the  Department  of  Defense  (DoD)  and 
its  military  departments  is  critical  to  national  defense  objectives  and  the 
acquisition  of  new  information  technology  (IT)  is  key.  The  DoD  seeks  to  quickly 
acquire  IT  systems  that  meet  requirements  and  are  within  budget;  however,  this 
goal  has  been  very  difficult  to  achieve  given  the  cumbersome  and  deliberate 
process  through  which  IT  systems  have  been  acquired.  Essentially,  the  DoD’s 
acquisition  process  cannot  keep  pace  with  the  rapid  development  of  IT  systems 
that  occurs  in  the  commercial  sector.  For  years,  the  DoD  has  relied  on  a  common 
approach  in  acquiring  different  systems  and  services.  This  approach  has  been 
laced  with  inefficiencies  and  inadequacies  that  have  resulted  in  prolonged 
schedules  as  well  as  increased  cost.  Currently,  the  DoD  is  implementing  a  new 
IT  acquisition  process;  however,  this  new  process  does  not  resolve  all  the  issues 
that  have  plagued  IT  acquisition.  This  study  will  identify  the  causes  or  impeding 
factors  that  have  prevented  the  DoD  from  acquiring  new  IT  systems  in  a  timely 
manner  and  will  recommend  alternative  solutions  to  solving  the  problems. 
Ultimately,  this  thesis  contributes  to  the  DoD’s  efforts  to  resolve  the  issues  that 
continue  to  undermine  timely  IT  acquisition. 
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I.  INTRODUCTION 


A.  INFORMATION  TECHNOLOGY  ACQUISITION  WITHIN  THE 

DEPARTMENT  OF  DEFENSE 

The  Department  of  Defense  (DoD)  has  leveraged  information  technology 
(IT)  extensively  in  order  to  build  national  security  systems,  business  systems, 
and  weapons  systems  in  the  interest  of  National  Defense  objectives.  The  DoD 
continues  to  invest  in  IT  capabilities  and  will  continue  to  rely  on  IT  systems  in 
order  to  meet  the  challenges  of  twenty-first  century  warfare.  IT  acquisition  is 
generally  defined  as  the  act  of  acquiring  or  gaining  new  technologies  in  order  to 
meet  a  specified  requirement  and  the  Defense  acquisition  system  is  the  method 
used  by  the  DoD  to  acquire  these  new  technologies.  For  the  DoD,  a  successful 
IT  acquisition  project  is  defined  as  a  project  that  is  delivered  on  time  and  on 
budget  with  the  required  features  or  functions  that  are  of  the  current  IT  product 
generation  or  current  with  regard  to  commercially  available  systems  (Gansler  & 
Lucyshyn,  2012). 

The  DoD  seeks  to  acquire  IT  systems  that  meet  requirements  quickly  and 
cost  effectively;  however,  this  endeavor  has  been  very  difficult  to  achieve  given 
the  cumbersome  and  deliberate  process  though  which  IT  systems  are  acquired. 
Moreover,  the  traditional  acquisition  system  cannot  keep  pace  with  the  rapid 
development  of  information  technology  systems  that  occurs  today.  In  2009,  a 
major  study  conducted  by  the  Defense  Science  Board  (DSB)  concluded  that  the 
traditional  DoD  acquisition  process,  as  described  in  DoD  Instruction  (DoDI) 
5000.02,  is  too  long  and  too  cumbersome  to  meet  the  needs  of  the  many  IT 
systems  that  require  continuous  changes  and  upgrades  (DSB,  2009). 

For  years,  the  DoD  has  relied  on  a  common  acquisition  method,  or  a  one- 
size-fits-all  approach,  for  acquiring  different  systems  and  services.  This  singular 
approach  has  been  laced  with  inefficiencies  and  inadequacies  ranging  from 
requirements  generation  and  funding  to  oversight  and  management  issues,  all  of 
which  have  contributed  to  prolonged  schedules  and  increased  cost.  It  is  critical 

1 


that  the  IT  acquisition  process  be  improved  in  order  to  increase  the  effectiveness 
of  employing  new  systems  to  meet  requirements  in  a  timelier  manner.  The  DoD 
has  earnestly  made  several  attempts  to  revamp  the  acquisition  system  to 
decrease  the  acquisition  cycle  time;  however,  it  appears  that  these  changes  have 
had  little  impact  because  the  timeline  remains  long  compared  to  the  commercial 
sector.  Commercial  technology  evolution  cycles  for  new  IT  systems  average 
12  to  18  months  but  fielding  of  useful  IT  systems  within  the  DoD  can  take  an 
order  of  magnitude  longer.  For  instance,  a  House  Armed  Services  Committee  in 
2010  found  that  the  delivery  of  systems  required  between  48  and  60  months 
(HASC,  2010).  This  is  problematic  since  the  commercial  IT  acquisition  process 
takes  approximately  one-fifth  of  the  time  it  takes  the  DoD,  which  results  in  the 
DoD’s  new  IT  systems  being  outdated  even  before  they  arrive  to  the  end  users. 
Therefore,  the  DoD  has  begun  to  implement  a  new  IT  acquisition  process  for  IT 
systems  designated  as  Defense  business  systems  (DBS).  This  new  IT 
acquisition  process  is  referred  to  as  the  Business  Capability  Lifecycle  (BCL)  and 
it  is  considered  a  first  step  in  responding  to  a  congressional  mandate  to  employ  a 
new  system.  However,  BCL  does  not  resolve  all  IT  acquisition  issues  due  to 
shortfalls  and  potential  problems  such  as  its  applicability  across  all  IT 
acquisitions  and  funding  methods  used  to  acquire  IT. 

It  is  clear  that  the  DoD  intends  to  improve  the  IT  acquisition  system  in 
order  to  acquire  IT  systems  in  a  more  timely  manner,  but  what  is  unclear  is  how 
the  DoD  will  do  so,  especially  in  the  wake  of  projected  defense  budget  cuts.  This 
thesis  will  discuss  the  causes  or  impeding  factors  that  prevent  the  DoD  from 
acquiring  new  IT  systems  in  an  expeditious  manner  and  will  recommend 
alternative  solutions  to  solving  the  problems.  Also,  this  thesis  will  include  a 
historical  perspective  of  acquisition  reform,  a  systematic  look  at  the  entire 
acquisition  process,  an  analysis  of  the  value  of  proposed  solutions,  and 
organizational  change  management  theory  as  it  relates  to  implementing  new 
processes  and  procedures  such  as  the  new  BCL  IT  acquisition  process. 
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B.  PROBLEM  STATEMENT 


This  thesis  seeks  to  address  the  DoD’s  acquisition  process  for  acquiring 
new  information  technology  (IT),  which  has  been  inadequate  in  keeping  pace 
with  the  commercial  industry’s  production  of  new  technologies.  This  is  a  problem 
because  as  the  IT  acquisition  cycle  time  increases,  so  does  cost;  but  more 
importantly,  benefits  are  slower  to  be  received  by  the  warfighter  or  the  end-user. 
As  a  result,  newer  and  potentially  better  technologies  always  are  available  first  in 
the  commercial  industry  and  perhaps  even  to  our  adversaries. 

C.  PURPOSE  STATEMENT 

The  purpose  of  this  thesis  is  to  explore  and  understand  the  issues 
involved  in  the  DoD’s  acquisition  process  for  information  technology  (IT)  in  order 
to  recommend  a  new  acquisition  approach  or  solutions  that  are  more  conducive 
to  keeping  pace  with  the  rapid  IT  development  cycle  found  in  the  commercial 
industry.  This  study  is  important  because  the  DoD  increasingly  depends  on  IT 
capabilities  and  IT  is  viewed  as  a  capability  that  will  provide  the  military  with  a 
competitive  advantage  in  achieving  information  dominance. 

D.  POTENTIAL  BENEFITS 

The  potential  benefits  that  may  result  from  this  thesis  are  a  better 
understanding  of  the  problems  within  the  DoD’s  IT  acquisition  system  in  order  to 
offer  feasible  solutions  or  recommendations  for  resolving  the  problems.  This 
thesis  contributes  to  the  DoD’s  efforts  in  resolving  the  issues  that  continue  to 
undermine  timely  IT  acquisition.  DoD  acquisition  stakeholders  could  benefit  from 
this  research,  as  new  approaches  to  the  acquisition  process  will  be  explored. 

E.  RESEARCH  METHODOLOGY 

Several  studies  conducted  since  2009  have  warned  of  IT  acquisition 
problems  in  regard  to  acquisition  cycle-time,  flexibility,  and  efficiency,  and 
recommended  reform  efforts  and  improvements  (e.g.,  development  of  a  separate 
IT  acquisition  process).  This  thesis  conducts  a  meta-analysis  of  this  previous 
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research  to  identify  common  elements  and  acknowledged  deficiencies  in  an 
effort  to  recommend  further  solutions. 

F.  BACKGROUND 

In  an  effort  to  understand  the  significance  of  the  IT  acquisition  issue 
before  delving  into  the  problems,  the  remainder  of  this  chapter  will  present 
background  information.  This  background  information  will  provide  an  overview  of 
the  IT  environment  within  the  DoD,  an  explanation  of  the  importance  of  IT  within 
the  Department  as  it  relates  to  strategy,  and  it  will  provide  an  introduction  to 
acquisition  policy  and  the  stakeholders  involved. 

1.  Overview  of  the  Information  Technology  Environment  within 
the  DoD 

a.  DoD  Dependence  on  Information  Technology  Systems 

Information  technology  (IT)  has  become  ubiquitous  across  the 
Department  of  Defense  (DoD)  with  a  disparate  set  of  uses  and  users.  IT  systems 
are  used  for  a  wide  variety  of  purposes  within  the  DoD  forming  an  “information 
enterprise”  as  defined  in  DoD  Directive  8000.01 : 

[The  DoD  Information  Enterprise  consist  of]  information  resources, 
assets,  and  processes  required  to  achieve  an  information 
advantage  and  share  information  across  the  Department  of 
Defense  and  with  mission  partners.  It  includes:  (a)  the  information 
itself  and  the  Department’s  management  over  the  information 
lifecycle;  (b)  the  processes,  including  risk  management,  associated 
with  managing  information  to  accomplish  the  DoD  mission  and 
functions;  (c)  activities  related  to  designing,  building,  populating, 
acquiring,  managing,  operating,  protecting,  and  defending  the 
information  enterprise;  and  (d)  related  information  resources  such 
as  personnel,  funds,  equipment,  and  IT,  including  national  security 
systems.  (DoD  Directive  8000.01,  2009) 

Information  is  the  key  enabler  of  the  Defense  Enterprise  as  was  identified 
specifically  in  the  2008  National  Defense  Strategy  (NDS,  2008).  The  DoD  and  its 
military  branches  have  taken  full  advantage  of  the  capabilities  afforded  by  new 
information  technologies.  The  U.S.  military,  in  particular,  has  been  enhanced  in 
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its  capabilities  due  to  the  profound  advances  in  IT  for  weapons  systems.  Among 
other  things,  the  DoD  has  greatly  benefited  in  the  areas  of  management  and  the 
overall  operations  of  the  Defense  Enterprise.  To  gain  these  important 
capabilities,  a  significant  portion  of  the  DoD  budget  is  spent  each  year  on 
acquiring  these  relentlessly  advancing  technologies  in  order  to  support  a  broad 
range  of  warfighting  and  functional  applications  (NRC,  2010).  The  ability  of  the 
DoD  and  its  industry  partners  to  harness  and  apply  advances  in  IT  for  command, 
control,  and  communications;  logistics;  and  transportation  has  contributed 
enormously  to  making  the  United  States’  military  the  best  in  the  world. 

So  pervasive  is  IT  that  it  has  become  an  essential  part  of  the  U.S. 
National  Defense  Strategy.  From  infrastructure  to  business  systems  to  IT 
embedded  in  weapons  systems,  the  DoD  is  completely  dependent  on  information 
technology.  While  the  importance  of  IT  continues  to  expand,  the  information 
technology  environment  is  experiencing  disturbing  trends  that  have  exacerbated 
the  issues  within  the  IT  acquisition  process.  Figure  1,  taken  from  the  2009 
Defense  Science  Board  Report  on  IT  acquisition,  depicts  growing  trends  within 
the  information  technology  environment  that  show  an  increase  in  IT  complexity, 
foreign  supply,  vulnerabilities,  threats,  and  cost  with  an  associated  decrease  in 
the  supply  of  U.S.  computing  graduates  and  qualified  expert  government  staff 
(DSB,  2009).  This  occurrence  is  considered  a  “perfect  storm”  in  regard  to 
information  technology  acquisition  because  it  further  exacerbates  IT  acquisition 
issues.  Additionally,  as  these  issues  occur,  the  rate  of  technology  change 
continues  to  increase  as  well  as  the  interconnectedness  of  systems,  which  pose 
additional  risks  for  the  DoD. 


5 


Figure  1 .  The  Perfect  Storm  (From  DSB,  2009) 


b.  Information  Technology  as  Defined  by  the  DoD 

For  the  purposes  of  this  study,  it  is  important  to  understand  how  the 
DoD  defines  information  technology.  Over  the  years,  information  technology  has 
been  defined  in  slightly  different  ways.  As  it  is  defined  in  the  1996  Clinger  Cohen 
Act,  formerly  known  as  the  Information  Technology  Management  Reform  Act, 

the  term  “information  technology” — 

(A)  with  respect  to  an  executive  agency  means  any  equipment  or 
interconnected  system  or  subsystem  of  equipment,  used  in  the 
automatic  acquisition,  storage,  analysis,  evaluation,  manipulation, 
management,  movement,  control,  display,  switching,  interchange, 
transmission,  or  reception  of  data  or  information  by  the  executive 
agency,  if  the  equipment  is  used  by  the  executive  agency  directly  or 
is  used  by  a  contractor  under  a  contract  with  the  executive  agency 
that  requires  the  use — 

(i)  of  that  equipment;  or 

(ii)  of  that  equipment  to  a  significant  extent  in  the 
performance  of  a  service  or  the  furnishing  of  a  product; 
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(B)  includes  computers,  ancillary  equipment  (including  imaging 
peripherals,  input,  output,  and  storage  devices  necessary  for 
security  and  surveillance),  peripheral  equipment  designed  to  be 
controlled  by  the  central  processing  unit  of  a  computer,  software, 
firmware  and  similar  procedures,  services  (including  support 
services),  and  related  resources;  but 

(C)  does  not  include  any  equipment  acquired  by  a  federal 
contractor  incidental  to  a  federal  contract.  (Clinger  Cohen  Act, 

1996) 

This  definition  outlines  IT  in  its  broadest  sense.  IT  can  be  generally  defined  as 
any  system  or  subsystem  of  hardware  or  software  whose  purpose  is  to  acquire, 
process,  store,  or  communicate  data  or  information  (DSB,  2009).  Also,  IT  can  be 
defined  as  those  systems  that  support  the  DoD  information  enterprise,  especially 
those  systems  expected  to  run  on  or  interface  with  existing  infrastructure, 
systems  that  are  user-facing,  and  is  limited  to  those  that  are  delivered  through 
the  acquisition  process  and  not  systems  developed  by  individual  commands 
(DSB,  2009).  For  the  purposes  of  this  study,  IT  is  defined  as  any  computer 
hardware  or  software  system  whose  purpose  is  to  acquire,  process,  store,  or 
communicate  information. 

c.  The  Rapid  Advancement  of  Information  Technology 

The  DoD  has  not  been  able  to  keep  pace  with  the  rapid 
advancement  in  IT  due  to  the  ineffectiveness  of  the  IT  acquisition  system. 
Information  technology,  both  software  and  hardware,  continues  to  rapidly 
advance  as  postulated  in  1965  by  Gordon  E.  Moore,  co-founder  of  Intel.  Moore 
(1965)  predicted  that  the  number  of  transistors  on  an  integrated  circuit  board 
would  increase  at  a  rate  of  roughly  a  factor  of  two  per  year;  he  later  refined  his 
projection  to  a  doubling  every  2  years  (DSB,  2009).  This  happening  is  referred  to 
as  Moore’s  Law.  Moore’s  Law  describes  an  exponential  growth  in  technology 
advancements  in  such  areas  as  computer  processing  speed  and  memory 
capacity.  For  example,  software  and  hardware  have  advanced  at  a  very  fast  rate 
over  the  past  several  decades,  from  isolated  standalone  computing  systems  in 
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the  middle  of  the  twentieth  century  to  networked  systems  that  span  the  globe 
today,  these  IT  advancements  have  been  transformational. 

With  rapid  technology  change,  we  are  experiencing  a  rapid  global 
increase  in  connectivity  among  computers  and,  consequently,  among  people 
(DSB,  2009).  Also,  the  spread  of  information  technology  has  shifted  the  roles  of 
citizen  and  state.  New  information  technologies  such  as  mobile  devices  and 
cheap  digital  storage  devices  have  provided  individuals  and  groups  with 
unprecedented  capabilities  to  organize  and  collaborate  in  new  ways.  Moreover, 
the  Internet,  social  networking,  on-line  search  engines,  video  teleconferencing, 
and  multimedia-enabled  smart-phones  are  but  a  sample  of  IT-based  capabilities 
that  have  altered  the  ways  in  which  people  communicate  (NRC,  2010).  The 
capability  the  DoD  possesses  through  information  technology  is  apparent  and  its 
uses  have  never  been  more  significant.  In  fact,  DoD  IT  systems  cover  a  broad 
range  of  diverse  technologies,  domains,  missions,  and  customers.  This  broad 
range  includes  support  to  National  Security  Systems  (NSS),  operational 
processes,  and  infrastructure  (see  Figure  2). 


Intent 


Customer 


Figure  2.  DoD  IT  Framework  (From  DSB,  2009) 
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2.  Importance  of  Information  Technology  to  the  DoD 

a.  The  Advent  of  the  Information  Age  and  Information 
Revolution 

The  Information  Age  and  the  Information  Revolution  have  brought 
with  it  a  plethora  of  personalized  products  and  services  and  a  powerful 
combination  of  centrally  supported  IT  and  end-user-driven  IT,  which  have 
changed  how  we  as  a  nation  do  business.  This  has  resulted  in  an  empowerment 
of  individuals  and  organizations,  giving  them  the  ability  to  innovate  their  technical 
capabilities  and  their  business  processes  (NRC,  2010).  At  the  same  time,  the  IT 
revolution  of  the  past  20  years — everything  from  hardware  and  software,  data 
standards,  and  commonly  agreed-upon  architectural  frameworks — has 
completely  permeated  the  national  security  enterprise.  Like  the  business  world, 
the  DoD  runs  on  information  and  seeks  to  gain  an  information  advantage. 
Information  technology  systems  not  only  underpin  the  business  practices  and 
management  of  the  Department,  but  they  have  become  integral  to  advanced 
weapons  systems  such  as  laser-guided  munitions  and  global  positioning  devices. 

The  importance  of  information  technology  to  military  capability  is 
inestimable.  IT  has  enabled  nearly  all  of  the  military’s  combat  capability  and  has 
become  a  necessary  element  of  critical  warfare  systems,  warfare  support 
systems,  and  Defense  business  systems.  This  study  focuses  on  IT  acquisition  as 
it  relates  to  Defense  business  systems  (DBS).  The  term  “Defense  business 
system”  is  defined  as  an  information  system,  other  than  a  national  security 
system,  operated  by,  for,  or  on  behalf  of  the  Department  of  Defense  for  activities 
such  as  acquisition,  financial  management,  logistics,  strategic  planning  and 
budgeting,  installations  and  environment,  and  human  resource  management 
(USD[AT&L],  2008).  The  designation  of  “business  system”  may  give  the 
impression  that  these  systems  only  relate  only  to  administrative-type  operations; 
however,  these  systems  have  a  direct  impact  on  warfighting  capability.  For 
instance,  all  military  operations  are  inherently  dependent  on  logistics  support 
systems,  and,  consequently,  the  business  systems  that  support  logistics 
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functions  are  considered  Defense  business  systems  (Gansler  &  Lucyshyn, 
2012).  Also,  IT  plays  a  significant  role  in  national  security  systems.  According  to 
the  Clinger  Cohen  Act  of  1996,  a  national  security  system  is  defined  as: 

A  telecommunications  or  information  system  operated  by  the 
federal  government,  the  function,  operation,  or  use  of  which: 

(A)  involves  intelligence  activities; 

(B)  involves  cryptologic  activities  related  to  national  security; 

(C)  involves  command  and  control  of  military  forces; 

(D)  involves  equipment  that  is  an  integral  part  of  a  weapon  or 
weapons  system;  or 

(E)  is  critical  to  the  direct  fulfillment  of  military  or  intelligence 
missions.  Does  not  include  a  system  to  be  used  for  routine 
administrative  and  business  applications  (including  payroll,  finance, 
logistics,  and  personnel  management  applications).  (Clinger  Cohen 
Act,  1996) 

Thus,  national  security  systems  include  satellites,  missiles,  tanks,  ships,  and 
planes  where  IT  is  embedded  within  the  system.  IT  touches  a  wide  range  of 
Department  systems  and,  in  turn,  enables  a  wide  range  of  capabilities. 

b.  Information  Technology  as  it  Relates  to  Military  Strategy 

Technological  advancements  have  created  a  new  world  for  military 
operations.  This  new  world  began  to  take  shape  at  the  turn  of  the  century  when 
the  DoD  developed  a  military  transformation  strategy  referred  to  then  as  Network 
Centric  Warfare  (NCW).  The  IT  acquisition  is  important  to  NCW  strategy  because 
the  strategy  relies  heavily  on  information  technology  being  available. 
Furthermore,  the  net-centric  strategy  is  a  capability  that  provides  the  DoD  with  a 
competitive  advantage,  which  is  essential  to  conducting  twenty-first  century 
warfare  in  the  Information  Age.  This  new  strategy  was  important  to  DoD’s 
transformation  into  the  Information  Age  and  remains  important  today.  To  gain  an 
appreciation  of  the  significance  and  the  urgency  of  solving  IT  acquisition  issues 
within  the  DoD,  it  is  necessary  to  understand  why  IT  is  so  important  to  the 
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Department  and  how  an  effective  military  strategy  is  closely  tied  to  an  effective  IT 
acquisition  system. 


c.  The  DoD’s  Net-Centric  Strategy 

In  the  late  1990s,  the  Department  of  Defense  (DoD)  began  a  force 
transformation  initiative  in  order  to  advance  the  military  into  the  Information  Age. 
This  initiative  was  facilitated  by  the  advent  of  new  technologies  and  the  need  to 
achieve  information  superiority  against  an  adversary.  The  concept  was  referred 
to  as  Network  Centric  Warfare  (NCW)  but  is  now  referred  to  as  net-centric 
capabilities  or  net-centric  operations.  The  concept  of  NCW  has  been  defined  in 
different  ways  throughout  its  history,  but  all  the  definitions  share  similarities.  In  its 
broadest  definition  as  provided  by  the  Command  and  Control  Research  Program 
(CCRP)  in  its  1999  publication,  Network  Centric  Warfare:  Developing  and 
Leveraging  Information  Superiority,  NCW  is  defined  as: 

An  information  superiority-enabled  concept  of  operations  that 
generates  increased  combat  power  by  networking  sensors, 
decision  makers,  and  shooters  to  achieve  shared  awareness, 
increased  speed  of  command,  higher  tempo  of  operations,  greater 
lethality,  increased  survivability,  and  a  degree  of  self¬ 
synchronization.  (Garstka  &  Stein,  1999) 

In  other  words,  the  NCW  strategy  is  characterized  by  the  linking  of  people, 
platforms,  weapons  systems,  sensors,  and  decision  aids  into  a  single  networked 
environment  (DoD  OFT,  2005).  The  NCW  theory  is  further  defined  in  terms  of  its 
four  tenets  that  describe  the  enhanced  power  of  a  networked  force:  (1 )  a  robustly 
networked  force  improves  information  sharing,  (2)  information  sharing  enhances 
the  quality  of  information  and  shared  situational  awareness,  (3)  shared  situational 
awareness  enables  collaboration  and  self-synchronization,  and  (4)  these,  in  turn, 
dramatically  increase  mission  effectiveness  (DoD,  2001). 

Network  Centric  Warfare  (NCW)  was  the  cornerstone  of  the  DoD’s 
transformation  process,  and  the  Department  placed  great  emphasis  on  the 
capabilities  produced  by  this  strategy.  In  fact,  much  had  been  accomplished  in 
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the  era  of  NCW  including  the  development  of  newer  technologies  and  systems, 
the  creation  of  new  military  occupational  specialties  (MOS)  and  departments  (i.e., 
the  Office  of  Force  Transformation,  now  defunct).  The  biggest  accomplishment 
has  been  the  impact  on  operations.  According  to  the  2006  Quadrennial  Defense 
Review  (QDR),  operational  experiences  in  both  Iraq  and  Afghanistan  have 
demonstrated  the  value  of  network  centric  warfare  (DoD,  2006).  In  both  theaters 
of  war,  critical  relationships  were  enabled  via  network-centric  capabilities  that 
allowed  for  faster  operational  decision  making.  By  harnessing  the  power  of 
information  through  connectivity,  operating  forces  were  able  to  gain  greater 
situational  awareness  and  show  the  value  of  NCW.  General  Stanley  A. 
McChrystal  (2010),  former  Commander  of  International  Security  Assistance 
Force  (ISAF)  and  U.S.  Forces  Afghanistan,  credited  network  centric  theory  in  his 
review  of  the  progress  experienced  in  Iraq  and  Afghanistan  (Younker,  2010). 
Furthermore,  the  special  operations  mission  that  targeted  Osama  bin  Laden 
exemplified  aspects  of  the  NCW  strategy  in  its  speed  and  agility,  collaboration 
with  higher  headquarters,  decentralization  of  the  small  unit,  and  decisive  speed 
in  accomplishing  the  mission  (Elkus,  2011).  These  recent  combat  experiences 
highlight  the  importance  of  IT  systems  with  its  ability  to  fuse  data  from  broad 
ranges  of  sources  both  within  and  outside  of  the  DoD. 

Although  there  has  been  some  success  in  using  the  net-centric 
strategy,  it  has  also  had  its  problems.  According  to  the  Defense  Science  Board 
(DSB)  (2009)  in  reference  to  a  2006  DSB  study  regarding  information 
management  for  net-centric  operations: 

Information  management  in  Iraq  and  Afghanistan  was  a  principal 
concern  among  warfighters.  Significant  ad  hoc  activity  was  taking 
place,  especially  at  the  tactical  level,  to  gain  desired  capability.  To 
counter  the  interoperability  problem,  many  approaches  were  used 
to  move  information  from  one  stove-pipe  to  another... much  of  the 
military  capability  used  to  support  the  conflicts  was  paid  for  with 
supplemental  funding — programs  that  were  not  part  of  the 
Department’s  planned  capability.  This  circumstance  reflects  the  fact 
that  the  need  for  such  programs  could  not  be  predicted  during 
previous  core  program  and  budget  planning,  and  the  system  was 
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not  sufficiently  agile  to  react  once  the  need  was  apparent.  (DSB, 

2009) 

These  problems  experienced  in  combat  were  due  in  large  part  to  not  having  the 
right  systems  in  place  to  better  manage  information  but  was  also  due  to  the 
ineffective  acquisition  process  that  was  in  use  to  facilitate  warfighter  needs  and 
requirements.  Despite  these  problems,  much  has  been  written  on  the 
advantages  and  benefits  resulting  from  the  net-centric  strategy  and  the  promise  it 
holds  for  the  future.  However,  the  implementation  of  the  net-centric  strategy  has 
not  come  without  challenges,  which  have  served  to  stymie  full  integration  of  the 
strategy. 

Some  of  these  challenges  to  implementing  the  net-centric  strategy 
can  be  linked  to  the  ineffectiveness  of  the  IT  acquisition  system.  The  DoD’s 
overall  strategy  for  implementing  NCW  theory  was  based  on  three  principles.  The 
first  principle  involved  setting  priorities  to  enable,  develop,  and  implement  net- 
centric  concepts  and  capabilities.  These  priorities  encompass  networking  a 
critical  mass  of  the  Joint  Force,  an  increased  emphasis  on  research  in 
developing  situational  awareness  and  approaches  to  achieving  synchronization, 
and  research  to  improve  the  DoD’s  ability  to  accurately  represent  net-centric 
related  concepts  in  models  and  simulations  (DoD  OFT,  2005).  The  second 
principle  consisted  of  establishing  specific  goals  and  measuring  progress.  The 
DoD  recognized  the  importance  of  establishing  measurable  goals  to  assess 
progress  and  validate  the  utility  of  the  net-centric  strategy.  The  third  principle 
consisted  of  overcoming  any  impediments  to  progress.  It  is  this  principle  that  has 
not  been  effectively  adhered  to  because  an  impediment  to  progress  is  in  the 
failure  to  acquire  IT  systems  in  a  timely  manner  in  order  to  meet  mission 
requirements.  Thus,  the  net-centric  strategy  has  not  been  fully  realized  in  the 
years  since  its  inception  due  to  a  number  of  issues  including  acquisition  related 
problems.  As  described  in  the  Defense  Science  Board’s  2009  report  to 
Congress,  failures  within  IT  acquisition  have  roots  in  the  failure  to  fully  realize  the 
vision  of  the  DoD’s  transformation  strategy: 
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Certainly,  barriers  that  preclude  transformation  of  the  U.S.  national 
security  apparatus  to  meet  the  challenges  of  a  new  strategic  era 
are  of  particular  concern.  Nearly  a  decade  ago  the  Department 
established  a  vision  for  the  architecture  and  structure  for 
information  system  management — a  vision  that  is  still  evolving. 
However,  it  is  well  known  that  acquisition  has  not  been  well 
managed  for  these  systems  within  this  “enterprise  level” 
construct,  and  the  result  has  not  served  today’s  leaders  and 
soldiers  well.  In  fact  it  hinders  the  warfighters’  ability  to  use 
information  technology  to  its  fullest  potential  for  situation 
awareness,  collaboration,  and  rapid  decision-making.  The  resulting 
operational  impact  is  profound.  (DSB,  2009) 

With  warfare  now  being  waged  in  the  Information  Age,  the  DoD 
may  be  at  risk  of  losing  its  competitive  advantage  of  information  superiority  if  IT 
acquisitions  do  not  enable  the  full  implementation  of  the  net-centric  strategy. 
Failure  to  implement  this  strategy  may  reduce  the  DoD  advantages  in  conducting 
twenty-first  century  warfare  and  place  the  military  at  a  disadvantage,  especially  in 
cyberspace.  The  2010  Quadrennial  Defense  Review  (QDR)  speaks  specifically 
about  how  operating  effectively  in  cyberspace  for  the  security  environment 
demands  improved  capabilities  to  counter  cyber  threats.  Furthermore,  modern 
armed  forces  simply  cannot  conduct  effective  high-tempo  operations  without 
resilient,  reliable  information  and  communication  networks  and  assured  access  to 
cyberspace  (Daggett,  2010).  Therefore,  it  is  imperative  that  the  DoD  work  to 
resolve  all  impediments  to  acquiring  newer  technologies  in  order  to  maintain 
information  superiority  in  warfare. 

The  war  on  terrorism  over  the  past  decade  has  shown  us  that 

national  security  threats  can  come  from  many  diverse  areas  including  domestic 

and  international  terrorists  groups,  state/non-state  actors,  computer  hackers,  and 

others.  It  is  clear  that  terrorist  groups  and  other  non-state  actors  have  come  to 

characterize  warfare  and  conflicts  in  the  twenty-first  century,  and  their  continued 

growth  and  power  will  remain  a  key  issue  of  the  information  environment.  Due  to 

globalization,  there  has  been  a  transformation  of  the  process  of  technological 

innovation  due  to  the  lowering  of  entry  barriers  for  a  wider  range  of  actors  and 

potential  adversaries  to  develop  and  acquire  advanced  technologies  (Daggett, 
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2010).  Adversaries  around  the  world  are  acquiring  these  new  technologies  and 
are  potentially  gaining  an  advantage  as  we  fail  to  acquire  newer  technologies  in 
an  effective  and  timely  manner.  The  speed  with  which  potential  adversaries  can 
adapt,  procure,  and  employ  newer  capabilities  against  the  United  States  has 
been  impressive.  Moreover,  our  adversaries  are  better  able  to  manipulate  the 
information  environment  by  employing  a  challenging  mix  of  tactics  and 
technologies,  which  will  increasingly  be  an  important  part  of  the  future  spectrum 
of  conflict  (Daggett,  2010). 

According  to  the  DoD  Chief  Information  Officer,  Teresa  Takai,  “U.S. 
networks  are  under  constant  attack  from  cyber  security  threats  launched  from  the 
Internet  or  from  malicious  software  embedded  in  e-mail  attachments,  removable 
media,  or  even  embedded  in  the  hardware  the  Department  procures”  (Improving 
Management  and  Acquisition  of  Information  Technology  Systems  in  the 

Department  of  Defense,  201 1).  Takai  goes  on  to  state  that,  “every  single  device 
connected  to  the  network  is  susceptible  to  a  cyber  attack”  (Improving 
Management  and  Acquisition  of  Information  Technology  Systems  in  the 

Department  of  Defense,  2011).  This  is  especially  concerning  because  the  DoD  is 
constantly  striving  to  integrate  and  network  more  and  more  systems,  so  we  are 
even  more  susceptible. 

Leveraging  information  technology  to  deliver  mission-critical 
information  capabilities  to  warfighters  is  one  of  the  primary  goals  of  IT.  There  was 
a  time  when  the  DoD  sought  to  balance  the  need  to  know  with  the  need  to  share 
information;  however,  today  the  warfighter  expects  to  have  and  needs  to  have 
the  latest  information  in  order  to  accomplish  the  mission  (Improving  Management 
and  Acquisition  of  Information  Technology  Systems  in  the  Department  of 
Defense,  2011).  The  need  to  know  the  latest  information,  coupled  with  the 
increasing  use  of  the  latest  technologies  from  smart  phones  to  mobile  computers, 
has  made  information-sharing  an  expectation.  Thus,  this  expectation  requires 
new  capabilities,  especially  in  tactical  environments.  IT  offers  inestimable 
capability  and  has  been  leveraged  extensively  in  order  to  build  national  security 
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systems,  business  systems,  and  weapons  systems.  As  the  Department 
continues  its  transformation  to  meet  the  challenges  of  the  twenty-first  century,  it 
will  continue  to  rely  on  the  increased  functionality  that  IT  provides,  so  acquisition 
processes  have  to  be  made  more  effective.  Thus,  the  continued  implementation 
of  net-centric  capabilities  via  effective  IT  acquisition  is  of  the  utmost  importance 
in  continuing  the  transformation  process  within  the  DoD. 

3.  Acquisition  of  Information  Technology  within  the  DoD 

a.  Information  Technology  Expenditures  within  the  DoD 

The  DoD  is  an  immensely  large  and  complex  organization  that 
consists  of  the  Office  of  the  Secretary  of  Defense  (OSD),  the  Joint  Chiefs  of  Staff 
(JCS),  the  military  departments,  numerous  defense  agencies  and  field  activities, 
and  various  unified  combatant  commands.  With  this  much  manpower,  the  DoD  is 
the  largest  organization  in  the  world,  with  operations  that  span  a  broad  range  of 
agencies,  activities,  and  commands.  Furthermore,  the  DoD  is  the  nation’s  largest 
employer  with  over  1.4  million  military  personnel  on  active  duty,  more  than 
750,000  civilian  personnel,  and  over  one  million  serving  in  the  National  Guard 
and  Reserve  (DoD,  2010).  Additionally,  there  are  nearly  6  million  military  family 
members  and  retired  personnel  who  receive  benefits. 

According  to  a  2010  Government  Accountability  Office  (GAO) 
report  regarding  DoD  business  transformation,  “in  fiscal  year  2009,  DoD  reported 
that  its  operations  consisted  of  $1.8  trillion  in  assets,  $2.2  trillion  in  liabilities, 
approximately  3.2  million  military  and  civilian  personnel  and  disbursements  of 
over  $947  billion”  (GAO,  2010).  Of  course,  this  2009  budget  may  not  rival  future 
defense  spending  given  the  current  fiscal  situation  within  the  federal  government, 
but  these  figures  point  out  the  large  sums  of  money  spent  within  the  DoD  and  a 
significant  portion  of  these  expenditures  are  used  for  acquiring  information 
technology. 

Much  like  the  commercial  business  world,  the  DoD  runs  on 
information  and  continues  to  require  more  and  more  of  it  via  IT  systems  in  order 
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to  achieve  an  information  advantage.  In  an  effort  to  support  the  diverse  IT 
requirements  of  the  DoD’s  huge  population,  the  DoD  employs  approximately 
15,000  unclassified  networks,  more  than  seven  million  computers  and  associated 
IT  devices,  and  a  170,000-person  information  management  and  information 
technology  workforce  (DoD,  2010).  With  these  large  numbers  of  systems,  it  is 
clear  that  information  technology  is  a  crucial  factor  in  every  aspect  of  the  DoD’s 
activities.  From  routine  e-mail  to  the  weapons  control  systems  in  the  most 
sophisticated  ships  in  world,  the  DoD  depends  on  the  smooth  functioning  of  a 
myriad  of  IT  systems  and  the  acquisition  process  that  provides  them. 

As  the  Information  Age  advances,  we  find  that  IT  systems  have 
expanded  both  in  complexity  and  in  pervasiveness  and  as  a  result,  they 
represent  one  of  the  largest  investments  for  the  DoD  today.  For  example,  the 
GAO,  which  is  the  investigative  arm  of  the  federal  government,  reported  that  in 
fiscal  year  2011  the  DoD  allotted  approximately  $36.6  billion  for  its  IT 
investments  and  $5.6  billion  of  this  amount  was  allotted  for  major  automated 
information  system  (MAIS)  programs  that  the  DoD  required  in  order  to  sustain 
key  operations  (GAO,  2013).  The  millions  of  people  who  are  employed  by  the 
DoD  operating  worldwide  maintain  an  inventory  of  systems  and  services  that 
accounts  for  these  expenses  and  it  is  an  order  of  magnitude  larger  than  any  IT 
expense  in  the  world.  The  DoD’s  IT  acquisition  expenditures  in  comparison  to 
other  DoD  expenditures  are  relatively  small  but  they  constitute  an  extremely 
important  business  function  within  the  Department.  However,  there  are  growing 
concerns  involving  all  DoD  expenditures  due  to  government  fiscal  issues  and 
projected  decreases  in  the  DoD  budget.  As  a  result,  IT  acquisition  issues, 
especially  the  IT  funding  process  issue  that  will  be  discussed  in  Chapter  II,  will 
only  be  exacerbated  in  the  event  of  budget  cuts. 
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b.  Acquisition  Policy  within  the  DoD 

The  purpose  of  the  Defense  acquisition  system  in  the  DoD  is 
explained  in  this  excerpt  from  DoD  Directive  (DoDD)  5000.01,  and  understanding 
this  sets  the  foundation  for  this  study: 

The  Defense  Acquisition  System  exists  to  manage  the  nation’s 
investments  in  technologies,  programs,  and  product  support 
necessary  to  achieve  the  National  Security  Strategy  and  support 
the  United  States  Armed  Forces.  The  investment  strategy  of  the 
Department  of  Defense  shall  be  postured  to  support  not  only 
today’s  force,  but  also  the  next  force,  and  future  forces  beyond  that. 

The  primary  objective  of  Defense  acquisition  is  to  acquire  quality 
products  that  satisfy  user  needs  with  measurable  improvements  to 
mission  capability  and  operational  support,  in  a  timely  manner,  and 
at  a  fair  and  reasonable  price.  (USD[AT&L],  2007) 

The  emphasis  of  this  thesis  relates  to  the  objective  of  acquiring  IT  “in  a  timely 
manner”;  however,  the  other  objectives  of  quality  products  and  reasonable 
pricing  are  equally  important  in  a  DoD  IT  acquisition  program.  A  DoD  acquisition 
program  is  generally  defined  as  a  directed,  funded  effort  that  provides  a  new, 
improved,  or  continuing  materiel,  a  weapon  or  information  system,  or  a  service 
capability  in  response  to  an  approved  need  or  requirement  shortfall  (USD[AT&L], 
2007).  The  Defense  acquisition  system  is  a  management  process  used  to 
provide  effective,  affordable,  and  timely  systems  (USD[AT&L],  2007). 
Additionally,  the  acquisition  process  includes  designing,  engineering,  testing  and 
evaluating,  production,  and  operations  and  support  of  Defense  systems  (Brown, 
2010).  As  used  herein,  the  term  “IT  acquisition”  will  apply  only  to  information 
technology  systems,  processes,  procedures,  services,  and  end  products  that  do 
not  include  weapons  systems  with  embedded  IT  (e.g.,  IT  that  provides  the  control 
systems  of  aircraft  weapons  platforms).  For  this  study,  IT  acquisition  will  only 
refer  to  military-unique  applications  that  support  intelligence,  logistics,  command 
and  control,  and  services  that  provide  basic  desktop  computing  and  other 
infrastructure  support.  Also,  this  study  refers  to  the  acquisition  of  major 
automated  information  systems  (MAIS)  that  are  associated  with  the  performance 
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of  routine  administrative  and  business  tasks  such  as  payroll,  accounting 
functions,  and  logistics  (Brown,  2010). 

For  many  years,  information  technology  acquisition  has  been  a 
subset  of  the  larger  acquisition  policy  within  the  DoD.  In  fact,  DoD’s  acquisition 
policies  and  regulations  were  primarily  designed  to  meet  the  needs  of  large 
weapons  programs  (NRC,  2010).  In  the  past,  it  has  taken  significant  tailoring  to 
accommodate  IT  programs  due  to  acquisition  instructions  focusing  almost 
exclusively  on  weapons  system  acquisition  and  on  Major  Defense  Acquisition 
Programs  (MDAPs)  such  as  ship  and  aircraft  procurement.  The  strategic 
guidance  used  to  shape  the  entire  Defense  acquisition  program  can  be  found  in 
the  department’s  acquisition  policies  and  regulations. 

The  two  major  DoD  regulatory  documents  that  guide  the 
management  of  Defense  acquisition  are  captured  in  two  documents:  DoD 
Directive  (DoDD)  5000.1,  “The  Defense  Acquisition  System,”  and  DoD  Instruction 
(DoDI)  5000.2,  “Operation  of  the  Defense  Acquisition  System.”  DoDD  5000.01 
provides  a  basic  set  of  definitions  and  three  overarching  policies  that  govern  the 
Defense  acquisition  system:  flexibility,  responsiveness,  and  innovation;  while 
DoDI  5000.02  intends  to  establish  a  simplified  and  flexible  management 
framework  for  translating  mission  needs  and  technological  opportunities  into 
stable,  affordable,  and  well-managed  acquisition  programs  (NRC,  2010).  Also, 
DoDI  5000.02  intends  to  establish  a  general  approach  for  managing  all  defense 
acquisition  programs  (NRC,  2010).  Although  DoDI  5000.02  has  good  intentions, 
the  instruction  does  not  effectively  support  the  acquisition  of  IT  systems.  In  fact, 
both  DoDD  5000.01  and  DoDI  5000.02  focus  almost  exclusively  on  weapons 
system  acquisition  and  on  MDAPs;  however,  DoDI  5000.02  contains  one  short 
section  on  IT  acquisition  found  in  Enclosure  5,  which  consists  of  only  3  pages  in 
the  80-page  document.  This  fact  leads  into  an  acquisition  problem  area  regarding 
the  inattention  to  IT  specific  acquisition,  a  fact  that  will  be  discussed  later. 

The  oversight  of  the  acquisition  system  is  an  essential  and 

important  part  of  the  acquisition  process  and  this  oversight  is  grouped  into  three 
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major  decision-support  systems:  the  Joint  Capabilities  Integration  and 
Development  System  (JCIDS);  the  Defense  Acquisition  System;  and  the 
Planning,  Programming,  Budgeting  and  Execution  (PPBE)  process.  These 
decision-support  systems  will  be  discussed  in  Chapter  III  but  a  general 
description  of  each  one  is  as  follows: 

The  Joint  Capabilities  Integration  and  Development  System  is  the 
system  that  identifies  and  documents  warfighter  needs  or 
requirements  (i.e.,  mission  deficiencies  or  technological 
opportunities);  the  Defense  Acquisition  System,  establishes  a 
management  framework  for  translating  the  needs  of  the  warfighter 
and  technological  opportunities  into  reliable,  affordable,  and 
sustainable  systems;  and  the  Planning,  Programming,  Budgeting 
and  Execution  Process  prescribes  the  process  for  making  decisions 
on  funding  for  every  element  of  the  Department,  including 
acquisition  programs.  (Brown,  2010) 

Additionally,  the  oversight  process  employs  a  layered  approach  to  oversight, 
which  is  based  on  the  level  of  investment  or  how  much  funding  is  provided  to  a 
program  (DSB,  2009).  All  programs  are  generated  at  the  component  level  along 
with  the  program  requirements.  Many  programs  are  reviewed  at  the  origin  by 
designated  component  milestone  decision  authorities  (MDAs).  The  most 
significant  investments,  programs  categorized  as  major  automated  information 
systems  (MAIS),  receive  additional  review  within  the  Office  of  the  Secretary  of 
Defense  (OSD)  (DSB,  2009).  Also,  there  is  congressional  oversight,  which  will  be 
discussed  further  in  the  next  section. 

For  purposes  of  program  management,  all  Defense  acquisition 
programs  are  broken  down  into  different  acquisition  categories  (ACATs).  Each 
ACAT  level  is  based  on  the  type  of  acquisition  desired,  its  dollar  value,  and  the 
level  of  milestone  decision  authority  (MDA)  it  rates.  MDA  is  the  action  of 
approving  or  disapproving  program  progress  or  advancement  into  follow-on 
phases.  There  is  a  chain  of  authority  along  with  organizational  players  who  are 
intimately  involved  at  each  ACAT  level.  ACAT  designations  for  automated 
information  systems  (AIS)  involve  systems  of  computer  hardware,  software,  data, 

or  telecommunications  that  perform  functions  such  as  collecting,  processing, 
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storing,  transmitting,  and  displaying  information;  excluded  are  computer 
resources  that  are  a  part  of  a  weapons  systems  (Brown,  2010).  Figure  3  displays 
ACATs  for  IT. 


Category 

Criteria  for  Designation 

Decision  Authority 

ACAT  IA 

•  Major  Automated  Information 

System  (MAIS) 

-  Designated  by  the  MDA 

as  an  MAIS,  or 

-  Estimated  to  exceed: 

■  Program  costs  in  any 
single  FY  (all  appro¬ 
priations),  $32M,  or 

■  Total  program  costs  (all 
appropriations)  from 
beginning  of  Concept 
Refinement  through 
deployment  at  all  sites, 

$1 26M,  or 

•  Total  life  cycle  costs  (all 
appropriations),  $378M 

•  MDA  designation  as  special 

interest 

•  ACATIAM: 

-  USD(AT&L)  or  designee 

-  Reviewed  by  the 

Information  Technology 
Acquisition  Board 

•  ACAT  IAC:  Component  head, 

or  Component  Acquisition 
Executive  (CAE)  (cannot  be 
further  delegated) 

-  Reviewed  by  component 

HQ 

ACAT  II 

•  Does  not  apply  to  MAIS 
programs 

•  N/A 

ACAT  III 

•  Does  not  meet  ACAT  IA  (MAIS) 
criteria 

•  Designated  by  the  CAE  at  the 

lowest  appropriate  level 

•  Reviewed  in  accordance  with 

component  policy 

Figure  3.  Acquisition  Categories  for  IT  (amounts  in  FY2000  constant  dollars) 

(From  Brown,  2010) 


Major  automated  information  system  (MAIS)  acquisition  programs 
are  designated  ACAT  IA  programs.  There  are  two  subcategories  of  ACAT  IA 
programs,  which  are  as  follows: 

•  ACAT  1AM,  for  which  the  milestone  decision  authority  is  the 
USD(AT&L)  or,  if  delegated,  the  Assistant  Secretary  of  Defense  for 
Networks  and  Information  Integration.  The  “M”  refers  to  major 
automated  information  systems  reviewed  by  the  Information 
Technology  Acquisition  Board. 
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•  ACAT  IAC,  for  which  the  milestone  decision  authority  is  delegated 
to  the  component.  The  “C”  refers  to  component.  After  the 
appropriate  headquarters  review,  the  Component  Acquisition 
Executive  (CAE)  makes  the  final  milestone  decision. 

•  The  ACAT  II  designation  does  not  apply  to  automated  information 
systems.  ACAT  III  automated  information  systems  are  those  that  do 
not  meet  the  criteria  for  ACAT  IA.  (Brown,  2010). 

c.  Defense  Acquisition  Management:  Key  Personnel  and 
Oversight 

There  is  a  chain  of  authority  and  many  organizational  players  who 
are  involved  at  each  ACAT  level  and  throughout  the  acquisition  process. 
Currently,  acquisition  authority  and  expertise  within  the  DoD  is  spread  across 
different  organizations,  which  is  problematic;  and  a  matter  that  will  be  discussed 
in  detail  later.  According  to  DoD  Directive  5134.01,  the  primary  management 
agency  of  the  DoD  Acquisition  System  is  the  Under  Secretary  of  Defense  for 
Acquisition,  Technology  and  Logistics  (USD[AT&L])  who  is  currently  Mr.  Frank 
Kendall  (DoD,  2008).  The  USD(AT&L)  is  the  principal  staff  assistant  and  advisor 
to  the  Secretary  of  Defense  and  Deputy  Secretary  Defense  for  all  matters 
concerning  acquisition,  technology,  and  logistics  (“Office  of  the  Under  Secretary 
of  Defense  for  Acquisition,  Technology  and  Logistics,”  n.d.,  Welcome  To  AT&L 
section,  para.  1).  The  primary  responsibilities  of  the  USD(AT&L)  include 
supervising  DoD  acquisition;  establishing  policies  for  acquisition  (including 
procurement  of  goods  and  services,  research  and  development,  developmental 
testing,  and  contract  administration)  for  all  elements  of  the  Department;  and 
establishing  policies  for  the  DoD  for  maintenance  of  the  Defense  industrial  base 
of  the  United  States  (“Office  of  the  Under  Secretary  of  Defense  for  Acquisition, 
Technology  and  Logistics,”  n.d.,  Welcome  To  AT&L  section,  para.  1).  The 
USD(AT&L)  also  serves  as  the  Defense  Acquisition  Executive  (DAE)  and 
Milestone  Decision  Authority  (MDA)  for  ACAT  IA  programs  as  identified  in  Figure 
3  under  Decision  Authority. 
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Two  other  OSD-level  organizations  or  offices  are  integral  to  the  IT 
acquisition  process:  the  DoD  Chief  Information  Officer  (formerly  the  Assistant 
Secretary  of  Defense  [Networks  and  Information  Integration/DoD  CIO])  and  the 
Office  of  the  Deputy  Chief  Management  Officer  (ODCMO)  for  the  DoD.  Due  to 
fiscal  concerns,  the  Assistant  Secretary  of  Defense  for  Networks  and  Information 
Integration  (ASD[NII]),  who  was  the  principal  OSD  staff  assistant  for  the 
development,  oversight,  and  integration  of  DoD  policies  and  programs  relating  to 
the  strategy  of  information  superiority,  was  dissolved  into  other  DoD  departments 
(“DoD  News  Briefing  with  Secretary  Gates  from  the  Pentagon,”  2010).  The 
ASD(NII)  was  dual-hatted  and  served  as  the  Chief  Information  Officer  of  the 
Department.  The  DoD  CIO  is  the  Principal  Staff  Assistant  (PSA)  and  advisor  to 
the  Secretary  of  Defense  (SECDEF)  and  Deputy  Secretary  of  Defense 
(DEPSECDEF)  and  is  tasked  with  improving  the  combat  power  of  the 
Department  by  ensuring  that  the  Department  treats  information  as  a  strategic 
asset  and  that  innovative  information  capabilities  are  available  throughout  all 
areas  of  DoD  supporting  warfighting,  business,  and  intelligence  missions  (“DoD 
CIO  Mission,”  n.d.).  The  DCMO  is  responsible  for  synchronizing,  integrating,  and 
coordinating  the  business  operations  of  the  Department  and  ensuring  optimal 
alignment  in  support  of  the  warfighting  mission  (“About  DCMO,”  n.d.,  About 
DCMO  section,  para.  1).  These  two  DoD  agencies  and  the  USD(AT&L)  comprise 
the  power  structure  of  the  DoD  acquisition  system;  however,  there  are  many 
other  entities  that  play  important  roles  and  also  hold  considerable  power. 

Other  important  entities  in  the  acquisition  process  involve  the 
Component  Acquisition  Executive  (CAE),  the  Program  Executive  Officer  (PEO), 
and  the  Program  Manager.  The  CAE  is  the  senior  official  in  each  DoD 
component  who  is  responsible  for  acquisition  matters  (Brown,  2010).  Normally, 
the  CAE  serves  in  a  primary  duty  capacity  as  either  the  secretary  of  the  military 
department  or  as  the  head  of  the  Defense  agency.  In  the  case  of  military 
departments,  the  secretaries  may  delegate  this  responsibility  to  the  assistant 
secretary  level,  which  is  then  referred  to  as  the  Service  Acquisition  Executives 
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(SAE)  (Brown,  2010).  The  PEO  is  normally  a  general  officer  but  can  also  be  a 
Senior  Executive  Service  (SES),  which  is  a  civilian  equivalent.  The  PEO  is 
responsible  for  first-line  supervision  of  a  group  of  like  programs  and  each 
managed  by  separate  Program  Managers  (PM)  (Brown,  2010).  Last,  and 
certainly  not  least,  is  the  Program  Manager  (PM). 

The  PM  is  arguably  the  most  significant  person  in  the  acquisition 
process,  not  necessarily  for  possessing  a  lot  of  power  but  due  to  his  or  her 
proximity  to  the  project.  The  PM  is  the  designated  individual  with  responsibility  for 
and  authority  to  accomplish  program  objectives.  These  objectives  include 
development,  production,  and  sustainment  to  meet  the  user’s  operational  needs 
(DoDD  5000.01).  Ultimately,  the  PM  is  accountable  for  what  is  considered  the 
holy  trinity  of  any  program  or  project:  cost,  schedule,  and  performance.  If  the  PM 
is  not  knowledgeable,  experienced,  and  consistent  in  terms  of  his  or  her 
availability  throughout  a  program,  the  IT  acquisition  process  is  more  likely  to 
experience  problems.  Unfortunately,  issues  surrounding  the  IT  acquisition 
workforce,  to  include  the  PM,  have  caused  problems,  which  will  be  discussed  in 
more  detail  later. 

There  are  many  other  DoD  agencies,  organizations,  and 
stakeholders  along  with  several  other  offices  within  the  Executive  Branch  that  are 
involved  in  the  acquisition  process.  In  no  particular  order,  these  entities  include 
the  following: 

•  IT  Acquisition  Advisory  Council 

•  Overarching  Integrated  Product  Teams  (OIPTs)  which  are 
specialized  review  teams 

•  Investment  Review  Board  (IRB) 

•  Chief  Information  Officers  (CIO)  for  the  military  departments 

•  Program  Analysis  and  Evaluation  (PA&E) 

•  Director  of  Defense  Research  and  Engineering  (DDR&E) 

•  Operational  Test  and  Evaluation  (OT&E) 
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•  Office  of  Management  and  Budget  (OMB) 

•  Office  of  Federal  Procurement  Policy  (OFPP) 

•  Federal  Acquisition  Regulations  Council 

•  Comptroller 

•  Operational  users  and  other  stakeholders  (Brown,  2010) 

All  these  different  entities,  plus  the  three  main  OSD-level  organizations  and/or 
personnel,  comprise  the  management  and  acquisition  team  or  acquisition 
workforce  for  the  entire  DoD  IT  acquisition  system.  The  three  main  entities 
provide  a  line  of  authority  in  the  acquisition  process  that  runs  from  the 
USD(AT&L),  through  the  CAE  and  PEO  to  the  individual  PMs  of  the  ACAT  IA 
programs  (Brown,  2010). 

With  all  the  different  agencies  and  organizations  involved  in  the 
acquisition  process,  it  can  be  very  difficult  to  get  anything  done  as  planned  or  as 
scheduled.  But,  there  unto  lies  the  problem  because  IT  acquisition  does  not 
always  get  done  according  to  plan  or  schedule  and  acquisition  workforce  issues 
are  just  one  of  the  problems.  Despite  the  DoD’s  success  in  leveraging  IT  across 
the  defense  enterprise,  the  acquisition  of  IT  systems  continues  to  be  burdened 
with  problems  that  result  in  a  failure  to  meet  the  primary  objective  of  Defense 
acquisition  which  again  is  “to  acquire  quality  products  that  satisfy  user  needs  with 
measurable  improvements  to  mission  capability  and  operational  support,  in  a 
timely  manner,  and  at  a  fair  and  reasonable  price”  (USD[AT&L],  2007).  The  next 
chapter  begins  the  discussion  of  the  crux  of  this  study,  which  will  explore  the 
problems  that  have  plagued  the  Defense  acquisition  system  over  the  past 
decade. 
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G.  ORGANIZATION  OF  THESIS 

The  thesis  is  organized  within  five  chapters.  Chapter  I  is  an  introduction  to 
the  problems  within  the  IT  acquisition  system  and  details  the  framework  for  this 
study.  Also,  Chapter  I  discusses  the  importance  of  IT  and  IT  acquisition  within 
the  DoD  in  order  to  achieve  national  defense  objectives.  Chapter  II  consists  of  a 
thorough  literature  review  of  the  acquisition  research  conducted  since  2009: 
government  reports,  academic  papers,  and  proposed  strategies  for  reforming  the 
IT  acquisition  system.  Chapter  III  discusses  background  information  on  IT 
acquisition  reform  efforts  and  an  overview  of  the  current  DoD  acquisition 
systems.  Chapter  IV  presents  an  analysis  of  both  benefits  and  shortfalls  of  the 
current  IT  acquisition  process  and  looks  at  other  potential  solutions,  offering  a 
recommended  approach  to  IT  acquisition.  Finally,  Chapter  V  closes  the  study 
with  persisting  issues  in  connection  with  the  current  IT  acquisition  system,  a 
summary,  findings  and  recommendations,  and  conclusion. 
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II.  LITERATURE  REVIEW 


This  chapter  consists  of  a  thorough  review  of  the  information  technology 
(IT)  acquisition  literature  that  has  been  written  since  2009.  This  literature  will 
include  government  reports,  articles,  academic  papers,  and  other  documents. 
The  goal  of  this  chapter  is  to  provide  the  reader  with  an  understanding  of  all  the 
major  problems  surrounding  IT  acquisition  within  the  DoD.  These  IT  acquisition 
problems  consist  of  a  misalignment  of  the  Defense  Acquisition  System  to  IT 
development,  lengthy  developmental  timelines,  testing  and  evaluation  issues, 
legislative  impediment  and  oversight,  requirements  and  funding  issues,  and 
acquisition  workforce  and  management  related  issues.  Ultimately,  this  chapter 
will  provide  an  extensive  look  at  these  problems  to  provide  a  context  in  order  to 
set  the  reader  up  to  begin  a  study  of  possible  solutions  which  will  be  discussed  in 
Chapters  III  through  V. 

A.  PROBLEMS  WITHIN  THE  DOD  IT  ACQUISITION  SYSTEM 

Information  technology  has  been  used  in  virtually  all  types  of 
organizations,  especially  government  and  business  organizations.  To  facilitate 
dealing  with  the  complex  tasks  and  business  operations  of  the  twenty-first 
century,  commercial  businesses  and  government  agencies  utilize  networked  IT 
systems  such  as  Enterprise  Resource  Planning  (ERP)  and  Supply  Chain 
Management  integration  in  order  to  enhance  their  operations.  However, 
commercial  businesses  (e.g.,  FedEx  and  Wal-Mart)  have  successfully  undergone 
a  fundamental  transformation  of  their  business  practices  via  information 
technology  while  government  agencies  have  been  less  successful  doing  so  and 
are  still  in  the  process  of  transformation  (Gansler&  Lucyshyn,  2012). 

Government  agencies  such  as  the  DoD  have  not  been  able  to  leverage 
the  full  potential  that  IT  systems  offer  in  regard  to  productivity.  In  fact,  the  DoD 
continues  to  lag  far  behind  the  capabilities  demonstrated  within  the  private  sector 
(Gansler  &  Lucyshyn,  2012).  The  DoD’s  “lagging  behind”  is  directly  linked  to  the 
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issues  found  within  the  IT  acquisition  system  today.  These  issues  present  a 
significant  problem  because  as  the  IT  acquisition  processing  times  increase,  so 
does  costs;  but  more  importantly,  benefits  are  slower  to  be  achieved.  With  that, 
there  has  been  growing  concern  among  the  DoD  and  Congress  that  our  nation’s 
military  advantage  may  be  eroding  due  to  the  problems  and  inefficiencies  within 
the  IT  acquisition  system.  It  is  important  now  to  take  an  extensive  look  at  what 
constitutes  the  problem  or  problems  with  the  DoD  IT  acquisition  system. 

There  have  been  no  shortages  of  studies,  reports,  and  reviews  that  have 
identified  many  of  the  problems  that  have  plagued  the  DoD  IT  acquisition  system. 
Thus,  there  is  a  recognized  and  compelling  need  to  address  these  problems, 
bottlenecks,  and  discontinuities  within  the  system.  This  review  of  the  IT 
acquisition  problems  will  analyze  the  following  six  documents,  which  include 
government  reports,  hearings,  articles,  and  academic  papers  that  have  described 
the  IT  acquisition  problems  over  the  past  several  years: 

•  Defense  Science  Board  Task  Force  on  DoD  Policies  and 
Procedures  for  Acquisition  of  IT  (DSB,  2009) 

•  Rapid  IT  Acquisition:  A  New  Model  for  Acquiring  Government 
Information  Technology  (Gilligan,  Heitkamp,  &  McCoy,  2009) 

•  Achieving  Effective  Acquisition  of  Information  Technology  in  the 
Department  of  Defense  (NRC,  2010) 

•  House  Armed  Services  Committee  Panel  on  Defense  Acquisition 
Reform  Findings  and  Recommendations  (HASC,  2010) 

•  A  New  Approach  for  Delivering  Information  Technology  Capabilities 
in  the  Department  of  Defense  (DoD,  2010) 

•  IT  Acquisition:  Expediting  the  Process  to  Deliver  Business 
Capabilities  to  the  DoD  Enterprise  (Gansler  &  Lucyshyn,  2012) 

The  authors  of  these  various  publications  place  similar  yet  different 
emphasis  on  what  they  construe  as  the  problem  or  problems  within  the  IT 
acquisition  system  but  all  have  ended  with  the  same  conclusion  that  these 
problems  need  to  be  resolved  in  order  to  make  the  IT  acquisition  system  more 
timely  and  effective.  Overall,  the  problems  identified  all  affect  the  three  things 
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that  are  most  important  to  any  acquisition  program:  cost,  schedule,  and 
performance.  Every  information  technology  acquisition  program’s  goals  are  to  get 
the  project  done  within  an  assigned  budget  and  on  time  while  providing  end 
users  with  the  required  capabilities.  Of  these  three  program  goals,  which  are  all 
important,  this  study  will  focus  on  the  scheduling  goal  because  scheduling  issues 
are  directly  related  to  DoD  agencies  and  the  warfighters  getting  needed 
capabilities  in  a  timely  manner  in  order  to  accomplish  their  specific  missions. 
Also,  scheduling  issues  have  a  direct  impact  on  cost,  which  in  this  current  fiscal 
environment  of  reduced  Defense  budgets  is  of  the  utmost  importance. 
Performance,  however,  is  a  separate  issue  all  together  and  will  not  be  discussed 
in  great  detail  but  it  will  be  discussed  as  it  relates  to  schedule. 

Of  the  six  documents  reviewed,  the  2009  Defense  Science  Board’s 
Department  of  Defense  Policies  and  Procedures  for  the  Acquisition  of 
Information  Technology  is  a  seminal  work  dealing  with  problems  in  DoD  IT 
acquisition.  In  fact,  the  problems  in  the  IT  acquisition  system  were  not  made  a 
priority  until  this  report  was  published.  All  of  the  other  documents  reviewed  here 
expand  from  the  issues  made  relevant  by  the  DSB  report.  IT  acquisition 
problems,  as  described  in  the  literature,  fall  into  six  categories  or  problem  areas 
that  are  as  follows: 

•  The  Defense  Acquisition  System  Ill-suited  for  IT  Acquisition 

•  Issues  Extending  From  Lengthy  Acquisition  Timelines 

•  Testing  and  Evaluation  Issues 

•  Legislative  Impediment  and  Oversight  Issues 

•  Requirements  and  Funding  Issues 

•  Acquisition  Workforce  and  Management  Issues 
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B.  THE  TRADITIONAL  DEFENSE  ACQUISITION  SYSTEM  ILL-SUITED 

FOR  IT  ACQUISITION 

As  stated  by  the  authors  of  Rapid  IT  Acquisition:  A  New  Model  for 
Acquiring  Government  Information  Technology,  “Information  Technology  tends  to 
have  different  characteristics  from  many  other  items  the  government  acquires, 
which  means  that  the  typical  government  acquisition  processes  are  not  optimum 
for  IT  procurements  (Gilligan,  Heitkamp,  &  McCoy,  2009).  The  authors  go  on  to 
state  that  “lengthy  and  deliberate  processes  used  to  acquire  weapons  systems  in 
DoD,  Coast  Guard  ships  for  the  Department  of  Homeland  Security,  or  a  nuclear 
fusion  test  laboratory  for  the  Department  of  Energy  would  not  be  good  models  for 
acquiring  tax  payment  processing  systems  or  law  enforcement  fugitive 
databases”  (Gilligan  et  al.,  2009).  Information  technology  acquisition  differs  from 
other  types  of  procurements  in  a  few  ways.  As  outlined  by  Gilligan,  Heitkamp, 
and  McCoy  (2009),  the  underlying  differences  in  IT  that  distinguishes  it  from 
other  types  of  procurements,  products,  and  services  are  as  follows: 

•  The  technology  for  information  systems  exhibits  continuous  and 
very  rapid  evolution. 

•  There  are  an  increasing  number  of  commercial  off-the-shelf 
(COTS)  components  available. 

•  Users’  requirements  for  an  information  system  evolve  as  users  gain 
experience  with  early  capabilities. 

•  Most  IT  systems  or  services  are  components  of  a  larger  “system  of 
systems.”  (Gilligan  et  al.,  2009) 

The  traditional  DoD’s  Acquisition  System  is  setup  to  support  larger 
procurements  or  platforms  such  as  weapons  systems,  ships,  and  aircraft.  Due  to 
procurement  laws,  regulations,  and  policies,  all  DoD  acquisitions  had  to  follow 
the  framework  of  the  Defense  Acquisition  System.  As  previously  mentioned,  the 
two  most  important  documents  governing  acquisition  are  DoD  Directive  5000.01 
and  DoD  Instruction  5000.02  and  both  are  focused  more  on  weapons  system 
acquisition  or  Major  Defense  Acquisition  Programs  (MDAPs)  than  on  information 
technology.  The  House  Armed  Services  Committee  (HASC)  in  2010  stated: 
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The  system  remains  structured  primarily  for  the  acquisition  of 
weapons  systems  at  a  time  when  [IT]  services  represent  a  much 
larger  share  of  the  Department’s  acquisitions.  As  a  result,  the 
Department’s  formal  acquisition  policy  has  limited  application  to  the 
majority  of  the  Department’s  acquisitions... Furthermore,  while  the 
Department  is  currently  working  to  modernize  in  the  “Information 
Age,”  the  acquisition  system  is  particularly  poorly  designed  for  the 
acquisition  of  information  technology.  (HASC,  2010) 

The  traditional  acquisition  system  lacks  the  flexibility,  agility,  and 
responsiveness  that  are  necessary  to  support  the  DoD  and  the  warfighter.  Thus, 
one  of  the  primary  acquisition  problems  is  the  DoD’s  “one-size-fits-all”  acquisition 
system  that  has  failed  to  produce  the  required  IT  systems  on  schedule  and  within 
budget.  According  to  Gansler  and  Lucyshyn  (2012)  in  IT  Acquisition:  Expediting 
the  Process  to  Deliver  Business  Capabilities  to  the  DoD  Enterprise,  “nearly  half 
of  all  major  federal  IT  projects  undertaken  have  experienced  delays  or  changes 
to  requirements  that  have  led  to  cost  and  schedule  overruns  and  program 
restructuring”  (Gansler  &  Lucyshyn  2012).  In  2010,  the  House  Armed  Services 
Committee  (HASC)  Panel  on  Defense  Acquisition  Reform  reported  that  the 
delivery  of  Defense  IT  systems  required  48  to  60  months  to  be  completed 
(HASC,  2010).  This  long  period  of  time  is  significant  based  on  the  fact  that  the 
commercial  acquisition  process  has  produced  newer  information  technologies 
much  quicker,  typically  within  a  fraction  of  the  time  it  takes  the  DoD. 

Some  of  the  IT  acquisition  time  taken  in  the  traditional  acquisition  process 
can  be  accounted  for  in  such  actions  as  risk  assessments  and  risk  reduction.  As 
stated  by  Timothy  Harp  (2009),  Deputy  Assistant  Secretary  of  Defense  for 
Command,  Control,  and  Communications,  Intelligence,  Surveillance, 
Reconnaissance  and  Information  Technology  Acquisition,  in  his  2009  testimony 
to  the  HASC  on  Acquisition  Reform,  “[the]  weapons  system  acquisition  process  is 
optimized  to  manage  production  risk  and  doesn’t  really  fit  information  technology 
acquisition  that  does  not  lead  to  significant  production”  (Challenges  to  Effective 
Acquisition  and  Management  of  Information  Technology  Systems,  2009).  Since 
the  threshold  of  risk  management  for  the  traditional  defense  acquisition  system 
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requires  a  higher  risk  than  for  the  typical  “mature  technology”  or  commercial  off- 
the-shelf  (COTS)  product  used  to  produce  Defense  business  systems,  the 
traditional  Defense  acquisition  process  does  more  harm  than  good  when 
acquisitioning  Defense  business  systems  (Gansler  &  Lucyshyn,  2012).  Moreover, 
the  design  of  the  traditional  acquisition  system  helps  to  reduce  the  risk 
associated  with  multibillion-dollar  investments  and  complex  weapons  programs 
by  using  repetitive  and  detailed  reporting  requirements  to  provide  visibility  so  that 
problems  can  be  identified  early  in  the  acquisition  process.  Long  durations  are 
understandable  for  weapons  system  acquisition  processes  due  to  the  extensive 
and  detailed  process  that  includes  Joint  Capabilities  Integration  and 
Development  System  (JCIDS)  initiation  through  full  development  (HASC,  2010). 
However,  Defense  business  systems  can  be  developed  with  less  inherent  risk  so 
extensive  and  repetitive  documentation  used  in  weapons  systems  acquisition  are 
problematic  and  result  in  more  time  spent  in  the  acquisition  process  (Gansler  & 
Lucyshyn  2012). 

C.  ISSUES  EXTENDING  FROM  LENGTHY  ACQUISITION  TIMELINES 

Commercial  IT  acquisition  processes  utilize  industry  standards  and  best 
practices  and  essentially  exercise  a  more  efficient  process  to  develop  newer 
technologies  in  a  timely  manner.  In  fact,  the  commercial  sector  is  able  to  deliver 
IT  capabilities  and  incrementally  improve  on  those  initial  deliveries  in  12  to 
18  months  (HASC,  2010).  With  Defense  IT  systems  typically  taking  48  to  60 
months  to  be  delivered,  DoD  system  are  not  as  timely  despite  two  major 
influences  that  encourage  more  timeliness.  The  first  influence  is  the  pace  of 
technology  change,  which  puts  pressure  on  acquisition  timelines  in  order  to 
ensure  relevancy  once  the  system  is  delivered  (DSB,  2009).  Given  the  nature  of 
the  Information  Age,  IT  acquisition  programs  are  greatly  affected  by  the  rapid 
pace  of  change  in  technologies.  As  mentioned  previously,  Moore’s  Law  predicts 
that  hardware  capability  per  unit  expenditure  doubles  roughly  every  18  months. 
In  a  commercial  market  environment  dominated  by  Moore’s  Law  and  a  high  rate 

of  technological  change,  hardware  obsolescence  and  supportability  has  become 
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a  significant  issue  that  has  affected  DoD  IT  acquisition  programs.  Software,  on 
the  other  hand,  is  driven  by  an  even-faster  pace  of  technology  change  due  to  the 
Internet  environment  and  end-user  expectations  (Gansler  &  Lucyshyn,  2012). 
Since  DoD  IT  acquisition  programs  progress  at  a  much  slower  rate,  the  DoD  is 
unable  to  keep  pace  with  the  rapid  rate  of  IT  innovation  in  the  commercial  sector, 
and  fails  to  fully  capitalize  on  IT-based  opportunities  (NRC,  2010). 

The  second  major  influence  on  IT  acquisition  timescales  are  military 
missions  and  operational  tempo  because  military  operations  are  requiring 
increasingly  more  rapid-response  times  (DSB,  2009).  Moreover,  decision  cycles 
in  conventional  warfare  have  shortened  from  days  to  hours  and  in  some  cases 
even  seconds.  As  reported  by  the  DSB  in  2009,  “the  overall  portfolio  of  DoD  IT 
programs  has  experienced  a  21 -month  delay  in  delivering  initial  operational 
capability  to  the  warfighter,  and  12  percent  are  more  than  four  years  late”  (DSB, 
2009).  Worse  yet,  once  the  delayed  product  is  received,  the  end  user  often  finds 
that  the  requirements,  technology,  and  standards  have  changed  or  the 
technology  is  already  two  or  three  generations  behind  (Gansler  &  Lucyshyn, 
2012). 

The  DoD  has  relied  on  an  acquisition  process  that  involved  many  non- 
integrated  parts  and  error-prone  processes  that  were  redundant  and  did  not 
provide  the  visibility  necessary  to  make  sound  IT  acquisition  management 
decisions.  Of  the  multiple  failings  of  the  Defense  acquisition  system,  one  major 
point  of  failure  has  occurred  at  milestone  decision  points.  Milestone  decisions  will 
be  covered  in  Chapter  III,  but  for  now  it  is  only  important  to  know  that  milestones 
are  critical  junctures  in  every  acquisition  program  where  a  program  must  gain 
approval  from  many  different  functional  organizations.  For  IT,  the  acquisition 
process  tended  to  stall  at  milestone  decision  points  because  when  a  system 
reached  certain  milestones,  it  could  take  up  to  90  days  for  a  milestone  decision 
to  be  reached  (DSB,  2009).  These  stoppages  or  delays  could  easily  increase  the 
schedule.  In  addition  to  the  milestone  decisions  delays,  excessive  program 
documentation  requirements  brought  on  by  the  traditional  acquisition  system 
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create  additional  delays  and  shifts  in  scheduling,  which  further  distance  the 
existing  process  from  commercial  best  practices  (Gansler&  Lucyshyn,  2012). 

D.  TESTING  AND  EVALUATION  ISSUES 

Testing  and  evaluation  (T&E),  as  it  relates  to  IT,  is  an  issue  in  the 
traditional  Defense  Acquisition  System.  Although  DoDD  5000.01  states  that  test 
and  evaluation  shall  be  integrated  throughout  the  Defense  acquisition  process, 
testing  is  often  integrated  too  late  in  IT  systems  acquisition  practices 
(USD[AT&L],  2007).  Testing  is  reserved  until  the  end  of  the  developmental  cycle 
or  administered  during  the  mandated  operational  testing  phase  in  a  realistic 
environment  (HASC,  2010).  Because  testing  does  not  occur  throughout  the 
development  cycle,  it  can  be  detrimental  to  the  effective  progress  of  Defense 
business  systems  acquisition  as  well  as  to  the  integration  and  interoperability 
objectives  sought  in  most  IT  projects.  Defense  business  systems  are  highly 
dependent  on  user  feedback,  which  can  be  integrated  into  the  product  in  the  form 
of  new  features  or  more  intuitive  design  (Gansler  &  Lucyshyn,  2012).  Failing  to 
conduct  continuous  testing  can  lead  to  more  developmental  time  due  to  intensive 
redesign  once  issues  are  discovered  following  large  blocks  of  untested 
development.  Essentially,  IT  systems  that  lack  continuous  testing  and  evaluation 
cause  not  only  delays  but  also  cost  overruns  while  limiting  the  potential 
effectiveness  of  the  product  (Gansler  &  Lucyshyn,  2012).  Also,  unnecessary 
testing  can  waste  time  and  cause  delays.  According  to  Teresa  Takai,  DoD  Chief 
Information  Officer  (CIO),  in  her  remarks  during  a  201 1  congressional  hearing  on 
improving  the  management  and  acquisition  of  IT  systems  in  the  DoD,  “we  will 
need  to  look  at  our  testing  and  accreditation  processes,  because  that  is  one  of 
the  inhibitors  that  we  are  aware  of  today  in  terms  of  retesting  platforms  for  every 
upgrade  as  opposed  to  recognizing  that  there  are  standard  platforms  and  there  is 
not  the  need  to  test”  (Improving  Management  and  Acquisition  of  Information 
Technology  Systems  in  the  Department  of  Defense,  201 1 ).  Takai’s  comment  is  in 
regard  to  the  use  of  commercial  systems  that  include  commercial  off-the-shelf 
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(COTS)  products  that  have  already  been  tested  and  approved  but  essentially  go 
through  a  retesting  process. 

In  regard  to  COTS  technologies,  they  are  not  only  inefficiently  tested  but 
they  are  also  insufficiently  leveraged,  excessively  tailored,  and  excessively 
delayed,  according  to  the  National  Research  Council  (NRC,  2010).  In  fact,  many 
programs  have  experienced  acquisition  lead  times  that  have  significantly 
exceeded  the  lifecycles  of  the  underlying  COTS  technology  by  years.  This 
happens  due  to  unnecessary  testing  but  also  to  oversight  processes  that  focus 
too  much  on  potential  shortcomings  of  COTS  products  and  services  (NRC, 
2010).  As  a  result,  this  approach  to  COTS  products  inhibits  the  timely  delivery  of 
meaningful  end-user  capabilities.  Ultimately,  the  processes  used  for  the 
acquisition  and  testing  of  IT  systems  can  last  more  than  5  years  before  a  solution 
is  delivered  to  the  end  users  (NRC,  2010).  Once  again,  given  the  rapid  pace  of 
change  in  the  IT  world,  solutions  eventually  delivered  within  this  time  frame  are 
often  found  to  be  inadequate  by  end  users. 

E.  LEGISLATIVE  IMPEDIMENT  AND  OVERSIGHT  ISSUES 

The  purpose  of  acquisition  oversight  in  the  DoD  is  for  the  disciplined 
management  of  large,  expensive,  and  complex  systems  (NRC,  2010). 
Throughout  the  government,  oversight  processes  are  exercised  by  multiple 
oversight  constituencies.  Oversight  for  a  government  IT  program  can  consist  of 
acquisition  officials,  CIOs,  DoD  officials,  and  even  Congress  that  authorizes  and 
appropriates  funds  and  enact  laws  governing  procurement.  Each  one  of  these 
entities  can  make  different  demands  (e.g.,  program  documentation,  reports,  and 
briefings)  as  they  exercise  their  oversight  roles.  With  multiple  oversight  bodies 
taking  part  in  the  program  oversight  and  review  process,  the  acquisition  system 
gives  undue  leverage  to  entities  that  often  are  not  true  stakeholders  (e.g.,  end 
users)  in  the  process  (NRC,  2010).  This,  imbalance,  of  course,  can  have 
negative  effects  on  the  program.  For  instance,  too  many  detailed  requirements 
can  be  included  in  the  program,  which  may  result  in  the  inability  to  prioritize  these 
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requirements  effectively.  Also,  these  different  requirements  could  be 
contradictory  or  extremely  difficult  to  implement.  Too  much  oversight  or 
governance  can  be  a  barrier  in  the  acquisition  of  IT.  For  example,  in  2009  the 
Defense  Acquisition  Performance  Assessment  Panel  stated,  “current  governance 
structure  does  not  promote  program  success — actually,  programs  advance  in 
spite  of  the  oversight  process  rather  than  because  of  it”  (DSB,  2009).  Although 
oversight  is  intended  to  be  a  good  thing,  some  oversight  entities  are  so 
burdensome  that  they  actually  slow  programs  down  and  even  increase  the 
probability  of  failure  (Gilligan  et  al. ,  2009). 

As  mentioned,  Congress  serves  in  an  oversight  role  and  is  very  much 
involved  in  addressing  the  issues  of  IT  acquisition.  In  fact,  the  Defense  Science 
Board  report  stated  “Congress  has  lost  confidence  in  DoD’s  execution  of  IT 
programs,  which  has  resulted  in  increasing  program  scrutiny  and  budget 
actions  (generally  funding  cuts)  for  programs  that  are  faltering”  (DSB,  2009). 
Furthermore,  this  loss  of  confidence  has  resulted  in  more  congressional 
involvement.  While  acting  in  their  oversight  role,  Congress  has  responded  to  IT 
acquisition  issues  by  adding  more  restrictive  legislative  mandates.  For  example, 
the  2007  National  Defense  Authorization  Act  contained  unprecedented  mandates 
involving  the  acquisition  of  IT.  These  mandates  defined  the  criteria  for  Major 
Automated  Information  Systems  (MAIS)  programs  and  required  annual  reports  to 
Congress  containing  the  following:  development  schedule  with  major  milestones; 
implementation  schedule  including,  estimates  of  milestone  dates,  initial 
operational  capability  (IOC)  and  full  operational  capability;  estimates  of 
development  and  lifecycle  costs;  and  a  summary  of  key  performance  parameters 
(DSB,  2009).  These  responses  to  acquisition  problems  have  not  only  created 
more  oversight  and  governance,  but  some  of  these  changes  were  excessively 
process-centric  and  even  adversarial  (NRC,  2010).  Even  though  congressional 
involvement  is  mandated  and  actually  necessary  at  times  (e.g.,  authorizing 
funding),  over  involvement  has  served  to  lengthen  the  IT  acquisition  process, 
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especially  since  these  mandates  create  a  focus  on  review  documents  and  other 
process  artifacts.  These  mandates  are  well-intended  changes,  but  they  have 
made  the  timely  delivery  of  IT  capabilities  even  more  difficult.  Lastly,  excessive 
involvement  by  Congress  could  become  even  more  problematic  if  ever  DoD 
begins  executing  programs  well  (DSB,  2009).  This  point  is  not  to  undermine 
congressional  authority,  which  is  clearly  outlined  in  the  Constitution;  however,  the 
point  is  simply  to  highlight  the  fact  that  some  congressional  processes  can 
become  convoluted,  confusing,  and  inefficient  for  the  DoD  acquisition  process. 

Another  oversight  issue  involves  cost  threshold  and  governance.  The  DoD 
acquisition  framework  prescribes  elaborate  governance  or  oversight  mechanisms 
and  cost  thresholds  that  trigger  varying  levels  of  review  (NRC,  2010).  As  shown 
in  Figure  3,  IT  programs  are  assigned  acquisition  categories  that  correspond  to 
the  estimated  acquisition  cost  and  are  then  aligned  to  the  oversight  level  based 
on  these  associated  cost  thresholds  (i.e. ,  assignment  to  a  DoD-level  agency, 
Service,  or  program  executive  officers).  The  problem  lies  in  the  total  dollar 
thresholds  for  designating  oversight  levels  for  IT  programs  because  these  dollar 
thresholds  are  significantly  lower  than  those  used  for  weapons  systems 
programs  (NRC,  2010).  The  result  creates  a  contrast  in  which  an  IT  system  that 
is  an  ACAT  IA  with  a  development  and  deployment  cost  of  $126  million  over  its 
lifecycle  has  highly  centralized  oversight  at  the  DoD-level,  while  a  weapons 
system  counterpart  at  the  same  dollar  amount  can  be  decentralized  for  oversight 
at  the  program  executive  officer  level  (NRC,  2010).  Again,  this  excessive 
oversight  creates  more  layers  to  traverse,  which  will  assume  more  transaction 
and  decision  time.  To  further  exacerbate  this  issue,  as  seen  in  Figure  3,  there  is 
no  provision  for  major  automated  information  system  (MAIS)  programs  to  even 
receive  oversight  at  the  Service  or  agency  level  (NRC,  2010). 
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F.  ISSUES  WITH  REQUIREMENTS  DETERMINATION  AND  FUNDING 

Requirements  determination  is  the  single  most  important  part  of  the 
acquisition  process.  Requirements  define  end  user  needs  and  expectations  but, 
also,  requirements  set  in  motion  the  intentions  and  actions  of  the  acquisition 
program.  Requirements  can  be  described  in  two  ways:  top-level  requirements 
(big-R)  and  detailed  requirements  (small-r).  The  difference  between  the  two 
relate  to  the  amount  of  information  that  is  required.  Big-R  requirements  convey  a 
widely  recognized  purpose,  mission,  and  expected  outcome  (NRC,  2010).  For 
example,  a  logistics  IT  system  would  be  assessed  on  the  basis  of  its  ability  to 
process  a  certain  number  of  logistics  requests  under  certain  conditions. 
However,  small-r  requirements  involve  a  set  of  more  detailed  requirements 
associated  with  specific  user  interfaces  and  utilities  such  as  the  ability  to  prioritize 
logistics  requests  based  on  time  or  unit  (NRC,  2010).  Both  types  of  requirements 
are  equally  important  and  both  can  be  a  source  of  problems  in  the  acquisition 
process. 

Issues  involving  requirements  have  served  to  lengthen  the  IT  acquisition 
cycle.  As  described  previously,  too  many  detailed  requirements  levied  on  IT 
programs  by  multiple  groups  can  be  problematic.  But  many  times,  IT  program 
requirements  are  initially  written  with  overly  detailed  specifications  (HASC,  2010). 
At  times,  these  specifications  are  inconsistent  with  the  pace  of  technological 
change  and  need  for  rapid  delivery  of  capabilities  to  the  end  user  (HASC,  2010). 
Also,  the  requirements  documents  have  often  been  inaccurate  descriptions  of 
end  user  needs.  The  consequence  is  seen  when  funding  is  obtained  and  the 
acquisition  process  is  initiated  because  any  newly  discovered  requirement  or 
need  may  not  be  covered  by  the  budget.  The  House  Armed  Services  Committee 
in  2010  found  that  the  “existing  requirements  process  is  ill-suited  for  the  rapidly 
evolving  nature  of  the  IT  marketplace  which  requires  an  iterative  dialogue  on 
requirements”  (HASC,  2010).  Moreover,  the  current  process  is  inflexible  and 
prone  to  over-specification  of  requirements.  As  has  been  the  theme  throughout 
this  study  thus  far,  DoD  acquisition,  budgeting,  and  requirements  processes  are 
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once  again  designed  for  large  weapons  systems  acquisition  programs,  and  the 
process  of  requirements  generation  is  being  inappropriately  applied  to  relatively 
low-dollar  IT  acquisition  programs  (NRC,  2010). 

Another  issue  that  is  closely  related  to  requirements  involves  the  funding 
process  for  IT  solutions,  which  normally  takes  years  and  does  not  support  a 
timely  acquisition  process.  The  source  of  this  funding  issue  is  the  DoD’s 
Planning,  Programming,  Budgeting,  and  Execution  (PPBE)  system.  The  entire 
DoD  budget  is  built  using  the  PPBE  system.  The  problem  is  that  this  system 
operates  on  a  timeline  that  does  not  align  well  with  the  fast-paced  IT  commercial 
marketplace  (DoD,  2010).  The  PPBE  offers  no  flexibility  or  concessions  for  IT  to 
be  able  to  respond  to  the  rapid  changes  of  the  IT  environment.  For  example, 
once  a  capability  shortfall  or  requirement  is  acknowledged  and  generated,  it  is 
then  linked  to  a  funding  request  to  Congress.  The  request,  however,  will  not  be 
provided  for  immediately  but,  instead,  funding  will  be  provided  in  a  future  year. 
An  issue  then  arises  when  solutions  that  will  rely  on  IT  have  to  wait  for  the 
funding  process.  For  instance,  the  time  frame  for  requesting  funding  can  be 
many  times  longer  than  the  actual  time  needed  to  develop  the  solution  (NRC, 
2010).  Essentially,  the  funding  allocation  process  is  not  responsive  enough  to 
address  capability  shortfalls  and  requirements  as  they  relate  to  IT  solutions.  Not 
only  does  funding  take  years  to  process,  but  also  another  complicating  factor  is 
that  IT  programs  are  funded  individually.  These  individual  funding  processes 
involve  three  principal  types  of  appropriation:  research  and  development, 
procurement,  and  operations  and  maintenance.  Also,  each  of  these  types  of 
appropriations  has  unique  rules  and  definitions  that  align  funding  to  a  particular 
program.  The  funding  problem  then  becomes  exacerbated  when  it  takes  years  to 
process  and  then  the  funding  is  not  flexible  to  permit  moving  it  around  to  support 
new  requirements  discovered  during  IT  development. 
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G.  ACQUISITION  WORKFORCE  CONCERNS  AND  MANAGEMENT 

ISSUES 

The  Acquisition  Workforce  includes  many  career  fields  such  as  auditor, 
contracting  officer,  program  management,  test  and  evaluation,  and  also 
information  technology  acquisition  personnel.  The  DoD  Acquisition  Workforce  is 
charged  with  procuring  systems  and  services  to  meet  warfighters’  requirements 
in  a  timely  manner  to  satisfy  national  security  objectives  (NRC,  2010).  This 
workforce  requires  highly  trained  specialists,  especially  in  the  areas  of  science, 
engineering,  testing,  business,  and  program  management.  These  highly  trained 
specialists  serve  as  acquisition  executives,  program  managers,  and  contracting 
officers  responsible  for  the  entire  acquisition  process.  In  recent  years,  a  number 
of  studies  have  expressed  concern  about  the  technical  proficiency  of  the  IT 
acquisition  workforce  and  its  future  status  because  relatively  few  in  the 
acquisition  workforce  have  specific  expertise  in  information  technology  (NRC, 
2010). 

In  the  Defense  Science  Board  2009  report,  a  review  was  conducted  of 
major  IT  acquisition  programs  (MAIS)  where  cost,  schedule,  and  performance 
were  issues.  These  issues  developed  from  three  root  causes:  1 )  senior  leaders 
lacked  experience  and  understanding,  2)  program  executive  officers  and 
program  managers  had  inadequate  experience;  and  3)  the  acquisition  process 
was  bureaucratic  and  cumbersome,  where  many  who  are  not  accountable  must 
say  “yes”  before  authority  to  proceed  is  granted  (DSB,  2009).  Chief  among  these 
problems  was  the  lack  of  experience.  IT  acquisition  experience,  along  with 
qualifications,  is  critical  for  the  DoD,  Service  leaders,  program  executive  officers, 
and  program  managers  to  make  the  right  decisions  within  an  IT  acquisition 
program  (DSB,  2009). 

Developing,  implementing,  and  managing  the  acquisition  process  of  IT 
systems  require  specific  and  extensive  technical  knowledge  along  with 
leadership  capabilities.  This  requirement  is  needed  at  the  DoD  level,  the 
Services,  and  within  the  larger  acquisition  community  as  a  whole  in  order  to 
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support  acquisition  oversight  and  decision  making  that  occurs  at  different 
milestones  (DSB,  2009).  However,  this  subject  matter  expertise  is  often  missing 
in  government  managers,  acquisition  personnel,  and  others  who  are  responsible 
for  program  execution.  Not  only  is  IT  expertise  missing  within  the  DoD,  but  also 
the  competition  for  talent  is  increasing,  especially  within  the  commercial  sector. 
Also,  both  government  and  the  commercial  sector  have  experienced  staffing 
difficulties  due  to  the  expected  retirement  of  many  in  the  IT  workforce,  the  small 
number  of  remaining  personnel,  and  the  dismal  outlook  of  incoming  personnel  to 
fill  the  ranks  (DSB,  2009).  The  deficiency  in  requisite  knowledge  and  expertise  in 
IT  acquisition  speaks  to  a  larger  problem  within  the  United  States  regarding 
trained  IT  professionals.  According  to  the  Defense  Science  Board  (2009),  the 
long-term  supply  of  U.S.  engineering  and  science  students  is  worrisome  and 
arguably  a  national  security  concern  because  over  the  past  10  years 
undergraduate  engineering  degrees  in  the  United  States  have  remained  flat 
whereas  South  Korea’s  have  risen  significantly  and  China’s  have  grown 
exponentially  (DSB,  2009). 

After  years  of  reducing  the  acquisition  workforce  in  the  1990s,  the  DoD 
has  greatly  increased  its  number  of  acquisition  personnel  but  they  possess 
limited  IT  acquisition  experience  (Fryer-Biggs,  2012).  According  to  Frank  Kendall 
(2012),  USD(AT&L),  acquisition  personnel  need  experience  and  that  takes  time. 
Kendall  also  stated: 

My  view  is  that,  at  the  end  of  the  day,  the  professionalism  and  the 
capability  of  the  workforce  and  how  it’s  supported,  more  than 
anything  else,  affects  acquisition  outcomes... We  grow  our  own 
people.  We  grow  our  program  managers.  We  grow  our  chief 
engineers.  We  grow  our  logistic  specialists,  our  private  support 
people.  We  grow  our  contracting  people.  And  if  we  have  a  shortfall 
on  that,  then  we  have  a  very  long  recovery  time  to  correct  it.  (Fryer- 
Biggs,  2012) 

The  DoD  has  the  means  to  develop  its  own  trained  professionals  but  even 
that  opportunity  is  limited.  The  Defense  Acquisition  University  (DAU)  is  the 
premier  source  of  acquisition  training  for  the  DoD.  This  training  emphasizes 

41 


systems  program  management  and  policy  compliance  among  other  things. 
However,  the  acquisition  curriculum  provided  by  DAU  through  the  years  had  not 
adequately  addressed  the  special  challenges  of  IT  system  acquisition. 
Essentially,  DAU  did  not  have  a  comprehensive  program  involving  IT  program 
management  and  IT  testing  and  evaluation,  or  training  courses  designed  to 

enhance  technical  skills  (NRC,  2010).  Due  to  this  shortfall,  DAU  was  not  able  to 
prepare  program  executive  officers  or  program  managers  to  run  IT  programs 
effectively. 

On-the-job  training  can  take  place  as  well,  but  this  training  is  not  always 
productive.  Program  mangers  that  typically  manage  weapons  systems  programs 
could  assume  a  PM  role  for  an  IT  program;  however,  even  if  that  program 
manager  proved  to  be  highly  successful  at  managing  weapons  systems 
acquisitions,  he  or  she  may  not  be  adequately  prepared  to  take  on  IT  systems 
management  given  the  nature  of  IT  technicality  and  specification  (DSB,  2009). 
Ultimately,  the  DoD  does  not  require  program  managers  to  have  IT-specific 
knowledge  or  experience  to  manage  IT  programs  and  this  inexperience  can  be 
detrimental  to  the  program  even  as  they  receive  on-the-job  training. 

Other  workforce  issues  as  described  by  the  National  Research  Council 
are  as  follows: 

•  The  DoD  rotates  personnel  too  often  for  any  one  PM  to  see  an 
acquisition  through  more  than  a  single  milestone 

•  The  acquisition  process  rewards  the  following  of  acquisition 
processes  rather  than  the  delivery  of  useful  and  usable  capability  to 
end  users 

•  The  military  culture  is  a  “can  do”  culture — no  program  manager 
wants  to  say  that  a  given  task  cannot  be  done 
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•  Program  size  is  used  as  a  success  metric  and  is  associated, 
overtly,  with  rank.  As  a  result,  program  managers  are  incentivized 
to  make  programs  larger,  which  contrasts  starkly  with  evidence 
from  many  studies  that  smaller  programs  reduce  cost  and  risk 
(NRC,  2010). 

Of  these  issues,  the  DoD’s  rotation  of  acquisition  personnel  is  especially 
problematic  along  with  military  personnel  who  are  rotated  before  an  acquisition 
process  has  matured.  Military  personnel  are  extremely  important  to  the 
acquisition  process  but  do  not  seem  to  possess  as  much  responsibility  as  the 
civilians  who  make-up  the  majority  of  the  IT  acquisition  workforce.  None  of  the 
literature  reviewed  here  specifically  discusses  what  the  military’s  role  is  or  ought 
to  be  in  addressing  the  IT  acquisition  problem.  Since  this  problem  affects  military 
capabilities  and  operations,  it  appears  that  uniformed  personnel  should  have  a 
larger  and  even  more  significant  role  in  the  IT  acquisition  process.  The  military 
role  as  it  stands,  at  least  for  military-specific  systems,  normally  relates  to  defining 
end  user  requirements  and  some  oversight  responsibilities  (i.e.,  Program 
Executive  Officer  or  Program  Managers).  In  regard  to  end-user  requirements,  the 
requirements  generation  portion  of  acquisitions  has  already  been  identified  as  a 
problem  area  within  the  IT  acquisition  process.  Military  personnel,  as  well  as 
civilian  acquisition  personnel,  limited  tenure  in  an  IT  acquisition  program  can 
create  discontinuity  and  experience  gaps,  and  can  hinder  program  progress.  This 
workforce  or  personnel  issue  speaks  to  the  overall  management  issues  that  have 
plagued  the  acquisition  system.  These  management  and  programmatic  issues 
begin  at  the  very  top  level  of  the  DoD  with  issues  of  roles  and  responsibilities. 

In  past  years,  and  perhaps  even  still,  DoD  agencies  have  had  issues  with 

roles  and  responsibilities  regarding  the  management  of  the  IT  acquisition  system 

(DSB,  2009).  These  issues  may  occur  because  acquisition  authority  in  the  DoD 

is  spread  across  several  different  organizations,  which  can  result  in  a  lack  of 

coordination  or  synchronization.  Although  the  Under  Secretary  of  Defense  for 

Acquisition,  Technology,  and  Logistics  USD(AT&L)  appears  to  have  the  most 
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control  over  IT  acquisition,  the  Secretary  of  Defense  has  many  other  offices  that 
contribute  to  the  decision-making  process  and  acquisition  of  information 
technology,  and  these  offices  serve  separate  functions  and  provide  different 
services  within  the  DoD.  These  various  DoD  offices  are  depicted  in  Figure  4  and 
include  the  Chief  Information  Officer  (CIO),  the  Comptroller/Chief  Financial 
Officer,  Operational  Test  and  Evaluation  (OT&E),  and  Deputy  Chief  Management 
Officer.  In  2009,  Congress  believed  that  IT  acquisition  problems  were  beyond  the 
scope  of  just  the  USD(AT&L)  and  that  they  were  a  problem  of  the  scope  of  the 
Secretary  of  Defense  (SECDEF)  because  many  of  the  agencies  that  perform  a 
function  in  the  acquisition  process  do  not  report  to  the  USD(AT&L)  (HASC, 
2009).  Often,  these  offices  are  not  aligned  and  according  to  Congress,  it  is 
unclear  if  these  organizations  are  serving  with  common  focus  toward  achieving 
improvements  in  the  IT  acquisition  process  (DSB,  2009). 


OSD  Organizational  Structure 

Principal  Staff  Assistants  (PSAs) 


Figure  4.  DoD  Organization  Chart  (From  “OSD  Organizational 

Structure,”  2013,  May  24) 
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The  IT  acquisition  system  is  seen  as  a  problem  not  just  within  the  DoD, 
but  also  across  the  entire  federal  government  because  the  same  acquisition 
policy  is  applied  throughout  government.  A  2008  GAO  report  found  that  nearly 
half  of  all  major  federal  government  IT  projects  were  re-baselined,  with  half  of 
those  being  re-baselined  more  than  once,  which,  of  course,  adds  more  time  to 
the  acquisition  process  (GAO,  2008). 

Despite  these  significant  acquisition  problems,  IT  has  been  a  great  benefit 
to  the  Department  and  its  military  services  and  has  changed  business  operations 
and  the  way  warfare  is  conducted.  However,  the  DoD  has  a  ways  to  go  in 
keeping  pace  with  the  Information  Age  as  evident  in  all  the  problems  that  have 
been  reviewed.  All  of  the  problems  described  throughout  the  literature  contribute 
to  the  overall  problem  within  the  IT  acquisition  system — the  failure  to  acquire  IT 
systems  in  a  timely  manner.  The  problems  are  imbedded  in  many  of  the  major 
processes  used  to  acquire  new  technology.  An  extensive  look  at  the  traditional 
acquisition  system  and  its  processes  will  be  described  in  Chapter  III.  This 
singular  process  has  hampered  IT  acquisition  with  acquisition-related  practices 
that  favor  large  programs,  high-level  oversight,  and  a  very  deliberate,  serial 
approach  to  development  (NRC,  2010).  Thus,  the  DoD  recently  began  an  IT 
acquisition  reform  effort  and  is  currently  fielding  a  new  IT  acquisition  framework 
to  address  many  of  the  problems  discussed.  Chapters  III  and  IV  will  examine  this 
new  acquisition  framework  and  its  ability  to  provide  the  solutions  to  the  IT 
acquisition  problems  described  in  this  chapter. 
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III.  REFORM  EFFORTS  AND  THE  CURRENT  IT  ACQUISITION 

SYSTEMS 


The  problems  identified  in  Chapter  II  have  persisted  for  many  years.  For 
this  reason,  there  have  been  many  reform  efforts  initiated  in  order  to  address  the 
various  problems  that  have  affected  the  overall  acquisition  system,  not  just  IT 
acquisition.  It  is  important  to  understand  previous  reform  efforts  because  they 
provide  a  context  with  which  to  assess  this  newest  reform  effort  and  the 
probability  that  it  will  solve  the  problems  identified.  This  chapter  will  begin  with  a 
brief  history  of  the  significant  reform  efforts  that  have  taken  place  over  the  past 
30  years  within  the  DoD  acquisition  system  and  how  each  reform  effort  has 
impacted  the  acquisition  process,  which  has  led  to  the  current  acquisition 
system.  Then,  this  chapter  will  take  an  extensive  look  at  the  current  acquisition 
system,  which  now  consists  of  two  separate  strategies  or  frameworks:  the 
traditional  Defense  Acquisition  System  framework  and  the  new  Business 
Capability  Lifecycle  (BCL)  framework,  which  is  exclusively  designed  for  Defense 
business  systems  and  major  automated  information  systems  (MAIS). 

A.  ACQUISITION  REFORM  HISTORY:  EARLY  1980s  TO  PRESENT 

The  acquisition  system  has  been  problematic  for  a  long  time  and  the  need 
to  reform  it  has  been  widely  acknowledged.  Since  the  early  1980s,  numerous 
studies  have  informed  the  DoD  of  the  shortcomings  of  the  acquisition  system. 
Many  of  these  studies  have  initiated  changes  to  policy  and  process.  Acquisition 
reform  initiatives  have  occurred  more  often  since  the  1980s  in  large  part  due  to 
information  technology  advancements  in  the  commercial  sector. 

In  the  early  1980s,  acquisition  reform  was  ushered  in  due  to  fraud,  waste, 
and  abuse  issues  found  within  the  acquisition  system  (Allen  &  Eide,  2012).  In 
response  to  these  issues,  a  commission  on  Defense  Management,  referred  to  as 
the  Blue  Ribbon  Commission,  was  instituted  along  with  new  legislation  that 
included  the  Goldwater-Nichols  DoD  Reorganization  Act  of  1986  (Allen  &  Eide, 
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2012).  The  Blue  Ribbon  Commission  reported  that  excellence  in  Defense 
management  will  not  emerge  simply  by  legislation  or  directive  alone,  but  that  the 
acquisition  workforce  must  be  empowered  to  succeed,  and  that  DoD,  the 
industrial  base,  and  Congress  must  all  set  aside  parochialism  to  restore  a  sense 
of  shared  purpose  and  mutual  confidence  (Allen  &  Eide,  2012).  Furthermore,  the 
commission  recommended  ways  to  improve  program  stability  in  order  to  mirror 
successful  industry  practices.  Some  of  these  recommendations  were  codified 
into  law.  In  regard  to  DoD,  the  Blue  Ribbon  Commission  found  that  diluted 
authority  of  execution  existed  within  the  Department,  so  a  major  restructuring 
ensued  as  a  result  of  the  Goldwater-Nichols  Act  (Allen  &  Eide,  2012).  As  a  result, 
the  National  Defense  Authorization  Act  for  fiscal  year  1987  directed  that  all 
acquisition  functions  be  consolidated  within  the  offices  of  the  Service  secretaries 
and  that  a  newly  created  position  of  the  Under  Secretary  of  Defense  for 
Acquisition  be  installed  (Allen  &  Eide,  2012). 

During  the  1990s,  the  Blue  Ribbon  Commission  recommendations  saw 
further  reform  introduced  that  impacted  how  the  DoD  viewed  its  workforce,  how  it 
conducted  commercial  practices,  and  how  it  did  business.  There  existed  a  need 
to  improve  the  quality  of  the  acquisition  workforce,  even  back  then,  so  the 
Defense  Acquisition  Workforce  Improvement  Act  (DAWIA)  of  1990  was  created. 
DAWIA  established  standards  for  education  along  with  a  specific  career  path  for 
the  acquisition  workforce.  One  of  the  most  significant  reforms  was  initiated  in 
1994  by  then  Secretary  of  Defense  William  Perry  who  directed  the  military 
departments  to  abandon  military  specifications  and  standards  when  contracting 
for  goods  and  services  (Allen  &  Eide,  2012).  Instead,  Perry  mandated  that  the 
military  departments  use  commercial  specifications  and  standards.  Also,  Perry 
mandated  the  use  of  the  Integrated  Product  and  Process  Development  (IPPD) 
and  Integrated  Product  Teams  (IPTs)  to  manage  program  execution  and  that 
cost  as  an  independent  variable  (CAIV)  would  be  used  to  control  cost  growth 
(Allen  &  Eide,  2012). 
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Also  in  the  1990s,  three  other  reform  efforts  took  place:  the  Federal 
Acquisition  Streamlining  Act  of  1994,  the  1996  change  to  the  Brooks  Act  of  1965, 
and  the  Clinger  Cohen  Act  of  1996.  The  Federal  Streamlining  Act  exempted 
procurement  of  commercial  items  from  existing  laws,  which  made  them  more 
prone  to  being  used  (Allen  and  Eide,  2012).  To  broaden  its  applicability,  the 
Federal  Streamlining  Act  also  expanded  the  definition  of  “commercial  product”  to 
include  many  other  items.  In  1996,  there  was  a  significant  change  to  the  1965 
Brooks  Act  regarding  information  technology.  Until  the  mid-1990s,  there  was  a 
separate  set  of  processes  and  policies  for  acquisition  of  DoD  IT  systems,  as 
called  for  in  the  Brooks  Act  of  1965  (NRC,  2010).  In  1996,  the  IT  and  non-IT 
policies  were  merged  because  the  requirements  of  the  Brooks  Act  and  other 
associated  processes  made  the  acquisition  process  too  cumbersome  and  slow 
(NRC,  2010).  Therefore,  IT  programs  fell  under  a  single  acquisition  process  that 
was  specified  in  the  DoD  5000  series  regulations.  This  reform  effort  was  intended 
to  provide  a  more  flexible  and  nimble  framework  for  all  types  of  programs; 
however,  not  long  after  the  IT  programs  were  consolidated  under  DoD  5000, 
there  developed  a  need  to  tailor  the  process  to  better  suit  the  needs  of  IT 
programs.  Since  then,  there  has  continued  to  be  a  need  to  tailor  the  process. 
Also,  there  have  been  repeated  efforts  to  reform  the  process  defined  by  the  DoD 
5000  series  in  order  to  address  persistent  challenges  in  the  IT  acquisition 
system,  which  continue  even  today.  Another  significant  event  in  the  1990s  was 
the  Clinger  Cohen  Act  (CCA)  of  1996,  which  was  a  landmark  reform  effort  in 
regard  to  information  technology.  The  CCA  began  as  two  separate  initiatives,  the 
Information  Technology  Management  Reform  Act  (ITMRA)  and  the  Federal 
Acquisition  Reform  Act  (FARA).  These  two  reform  acts  were  eventually 
combined  and  were  subsequently  designated  the  Clinger  Cohen  Act  after  being 
signed  into  law  as  part  of  the  National  Defense  Authorization  Act  for  Fiscal  Year 
1996  (CCA,  2006).  The  CCA  also  established  the  position  of  Chief  Information 
Officers  (CIO)  in  government  agencies  along  with  their  roles  and  responsibilities 
(CCA,  2006).  Furthermore,  the  CCA  directed  federal  agencies  to  focus  on  the 
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results  achieved  through  IT  investments  and  a  continuation  of  the  streamlining  of 
the  federal  IT  acquisition  process  (Allen  &  Eide,  2012).  The  CCA  also  eliminated 
cost  accounting  standards  that  had  discouraged  the  commercial  industry  from 
doing  business  with  the  government  (Allen  &  Eide,  2012).  Ultimately,  the  Federal 
Streamlining  Act  and  the  Clinger  Cohen  Act  created  a  reduction  in  government 
red  tape  and  allowed  more  commercial  innovation,  both  of  which  were  viewed  as 
key  enablers  to  improving  acquisition  outcomes.  The  1990s  would  see  one  final 
reform  in  1997  when  then  Secretary  of  Defense  William  Cohen  instituted 
additional  acquisition  reforms  under  what  was  referred  to  as  the  Defense  Reform 
Initiative  (DRI).  This  initiative  identified  four  pillars  of  reform:  1)  a  re-engineering 
to  adopt  commercial  business  practices,  2)  a  consolidation  to  streamline 
organizations  to  eliminate  redundancy  and  maximize  synergy,  3)  more 
competition  in  the  market  to  improve  quality  and  reduce  costs,  and  4)  elimination 
of  excess  support  structures  to  free  resources  and  focus  on  core  competencies 
(Allen  &  Eide,  2012).  Essentially,  the  1990s  offered  a  more  business-minded 
approach  to  addressing  acquisition  issues  and  this  approach  carried  over  into  the 
next  century. 

The  turn  of  the  century  came  with  revolutions  in  military  affairs,  as 
mentioned  in  Chapter  II  with  concepts  such  as  net-centric  operations,  which 
prompted  further  revolutions  in  the  way  the  DoD  conducted  business.  One  of  the 
central  figures  in  ushering  in  these  reforms  at  the  turn  of  the  century  was  then 
Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics 
(USD[AT&L])  Jacques  Gansler,  who  continues  to  influence  the  acquisition 
community  today.  In  response  to  studies  directed  by  Congress  in  the  early 
2000s,  Gansler  sought  a  new  direction  through  acquisition  reform  that  included 
three  goals:  1)  reduce  developmental  cycle  times  for  new  weapons  systems; 
2)  reduce  total  costs;  3)  and  right-size  the  Defense  Acquisition  Workforce  and 
infrastructure  in  the  new  business  environment  in  order  to  realize  savings 
through  efficiencies  and  maximizing  flexibility  (Gansler,  2000).  These  efforts 
included  training  of  the  acquisition  workforce  on  commercial  practices,  a  focus  on 
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cost  and  schedule  over  performance,  and  an  increased  reliance  on  an  integrated 
civil-military  industrial  base  (Allen  &  Eide,  2012).  These  efforts  did  not  have  an  IT 
emphasis  although  they  related  to  IT  as  well.  Also  during  this  time,  then 
Secretary  of  Defense  Donald  Rumsfeld,  with  his  own  business-minded  approach 
to  transformation,  thought  buying  the  right  thing  was  just  as  important  as  buying  it 
right  (Allen  &  Eide,  2012).  Furthermore,  Rumsfeld  believed  that  network-centric 
capabilities  were  more  important  to  future  conflict  than  the  traditional  and  ever¬ 
present  legacy  systems,  which  needed  to  be  replaced  (Adler,  2007).  Riding  the 
wave  of  the  new  Information  Age,  Rumsfeld  worked  to  ensure  that  the  DoD 
sought  innovation  from  nontraditional  defense  industries  that  embraced 
technology  capabilities. 

Leading  up  to  the  turn  of  the  century,  the  acquisition  strategy  most  often 
employed  was  the  “waterfall”  method  for  IT  development.  In  the  waterfall  model, 
well-defined  increments  of  information  technology  were  designed,  developed, 
and  fielded  in  a  pre-specified  order  in  a  waterfall  or  cascading  process  (NRC, 
2010).  The  waterfall  model  involved  a  specific  and  inflexible  process  that 
required  documented  specifications  and  a  request  for  bids,  followed  by 
contracting,  delivery,  installation,  and  maintenance.  Additionally,  the  waterfall 
method  was  document-intensive  in  order  to  satisfy  the  management  goal  of 
successfully  meeting  program  objectives.  One  of  the  main  disadvantages  of  the 
waterfall  process  was  that  it  emphasized  the  acquisition  process  rather  than  the 
capability  being  acquired  (NRC,  2010).  The  increments  were  sequential  and  any 
deviations  called  for  a  new  baseline,  which  generally  triggered  a  complete 
program  review.  These  reviews  were  problematic  because  approvals  at  each 
step  up  the  acquisition  approval  chain  often  became  more  difficult  to  obtain 
(DSB,  2009).  The  result  was  usually  an  increase  in  the  time  required  to  deliver  an 
increment  and  the  overall  program  (DSB,  2009). 

The  waterfall  acquisition  model  delivered  acceptable  results  when 
developing  and  delivering  technologies  or  requirements  over  a  relatively  long 
time  frame;  however,  when  that  time  frame  needs  to  be  shorter,  such  as  is  the 
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case  for  IT,  the  deliberate  and  sequential  process  of  the  waterfall  model  did  not 
work  well.  As  mentioned,  IT  resides  in  a  domain  where  change  occurs  very  often 
and  in  shorter  time  frames  and  the  potential  ability  of  adversaries  to  employ 
these  new  technologies  quicker  than  the  DoD  is  even  more  concerning.  Reform 
was  inevitable  as  the  GAO  concluded  in  its  2008  assessment.  GAO 
recommended  a  fundamental  change  in  the  acquisition  environment  due  to 
systemic  problems  not  only  with  the  process,  which  was  viewed  as  not  being 
agile  enough  to  support  current  operations,  but  also  in  the  requirements 
generation  process  (DSB,  2009).  Others  involved  in  the  acquisition  process, 
including  Congress,  made  similar  conclusions  that  the  waterfall  process  was  too 
document-intensive,  time-consuming  and  process-oriented  to  be  able  to 
effectively  respond  to  end-user  requirements  (HASC,  2010).  Ultimately,  this 
acquisition  method  was  deemed  inappropriate  and  a  change  was  afoot  via  more 
reform.  The  DoD  would  eventually  shift  to  an  evolutionary  acquisition  method, 
which  replaced  the  waterfall  method,  as  described  in  DoDI  5000.02: 

Evolutionary  acquisition  is  the  preferred  DoD  strategy  for  rapid 
acquisition  of  mature  technology  for  the  user.  An  evolutionary 
approach  delivers  capability  in  increments,  recognizing,  up  front, 
the  need  for  future  capability  improvements.  The  objective  is  to 
balance  needs  and  available  capability  with  resources,  and  to  put 
capability  into  the  hands  of  the  user  quickly.  The  success  of  the 
strategy  depends  on  phased  definition  of  capability  needs  and 
system  requirements,  and  the  maturation  of  technologies  that  lead 
to  disciplined  development  and  production  of  systems  that  provide 
increasing  capability  overtime.  (USD[AT&L],  2008) 

Although  the  evolutionary  approach  is  more  conducive  to  IT  acquisition,  the 
approach  did  not  solve  all  the  problems  and  neither  did  DoDI  5000.02  because  it 
still  focused  mainly  on  the  procurement  of  weapons  systems. 

Despite  all  the  extensive  acquisition  reform  efforts  that  began  in  the 
1980s,  the  DoD  and  Congress  began  to  lose  confidence  in  the  acquisition 
system  by  2005  and  felt  that  the  system  was  broken  (Report  by  the  Assessment 
Panel  of  the  Defense  Acquisition  Performance  Assessment  Project,  2006).  Upon 

this  conclusion,  the  Defense  Acquisition  Performance  Assessment  (DAPA) 
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Project  was  established  and  in  2006  it  conducted  an  integrated  assessment  of 
the  entire  acquisition  process.  One  of  DAPA’s  major  findings,  like  previous 
efforts,  identified  excessive  oversight  and  complex  acquisition  processes  as  cost 
and  schedule  drivers  (Allen  &  Eide,  2012).  Also,  DAPA  cited  that  stability  of 
requirements  is  essential  for  the  acquisition  system  to  be  effective.  In  2009,  the 
Defense  Science  Board  (DSB)  took  one  of  the  first  comprehensive  looks  at  the 
DoD’s  acquisition  process  as  it  relates  to  IT  systems  and  found  that  it  was  simply 
too  long  and  ineffective,  and  did  not  accommodate  the  rapid  evolution  of 
information  technology  (DSB,  2009).  Furthermore,  oversight  ambiguity  along  with 
management  issues  were  viewed  as  significant  problems  that  needed  to  be 
addressed.  Thus,  the  DSB  recommended  the  development  of  a  new  acquisition 
and  requirements  development  process  for  IT  systems  that  would  be  agile  and 
incremental,  and  allow  requirements  to  be  prioritized  based  on  need  and 
technical  readiness  (DSB,  2009).  These  DSB  recommendations  were  eventually 
approved  and  implemented  into  policy.  According  to  Gansler  and  Lucyshyn 
(2012),  this  act  was  certainly  a  step  in  the  right  direction  because  congressional 
oversight  occasionally  created  ambiguities  in  the  DoD’s  acquisition  process 
(Gansler  &  Lucyshyn,  2012).  Moreover,  Gansler  and  Lucyshyn  stated: 

The  Goldwater-Nichols  Act,  the  Clinger  Cohen  Act,  and  the  2005, 

2007,  and  2009  NDAAs  lacked  clarity  with  regard  to  specific 
features  of  their  implementation.  Rather  than  promoting  innovation 
and  flexible  responses  to  acquisition  problems,  the  ambiguities  led 
to  the  creation  of  more  structure,  which,  in  turn,  increased  the 
amount  of  documentation.  Although  these  congressional  acts  may 
have  reduced  systemic  risk,  they  also  prompted  cost  increases  and 
programmatic  delays.  (Gansler  &  Lucyshyn,  2012) 

Essentially,  Goldwater-Nichols,  Clinger  Cohen  and  the  federal  laws  that  ensued 
continued  to  complicate  the  IT  acquisition  process  and  caused  overlapping 
responsibilities  between  the  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics  (USD[AT&Lj),  the  Department’s  CIO,  and  the  Deputy 
Chief  Management  Officer. 
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The  Obama  administration  initiated  the  most  recent  acquisition  reform 
initiatives;  however,  some  of  which  did  not  go  far  enough  in  terms  of  IT.  For 
instance,  the  December  2008  revisions  to  DoD  Instruction  5000.02  offered 
improvements  to  the  process  but  did  not  address  the  fundamental  challenges  of 
acquiring  information  technology  for  its  range  of  uses  in  the  DoD.  In  2009,  former 
Secretary  of  Defense  Robert  Gates  instituted  his  own  vision  of  needed 
acquisition  reform  that  was  much  like  Rumsfeld’s  affirmation  that  buying  the  right 
thing  was  as  important  as  buying  it  right  when  he  stated  that  “we  must  reform 
how  and  what  we  buy... meaning  a  fundamental  overhaul  of  our  approach  to 
procurement  acquisition  and  contracting”  (Gates,  2009).  Furthermore,  Gates 
emphasized  that  significant  change  would  be  necessary  to  maintaining  military 
superiority  in  an  environment  of  ever  shrinking  economic  resources  and  a 
reduced  Defense  budget.  Gates  identified  three  fundamental  steps  to  reform: 

1)  senior  leaders  must  demonstrate  commitment  and  courage  to  discontinue 
failing  programs  and  programs  that  procure  more  capability  than  necessary, 

2)  performance  requirements  must  be  scrutinized  as  necessary  in  order  to  avoid 
cost  and  schedule  overruns,  and  3)  government  program  teams  should  be 
adequately  staffed  for  proper  oversight,  cost  estimates  should  be  more  realistic, 
and  budgets  should  be  protected  for  program  stability  (Allen  and  Eide,  2012). 

Finally,  Congress  passed  the  2010  National  Defense  Authorization  Act 
(NDAA)  Section  804  in  response  to  the  Defense  Science  Board’s  2009  report 
concerning  IT  acquisition  issues.  Section  804  called  for  the  development  and 
implementation  of  a  new  acquisition  process  for  IT  systems,  in  particular  Defense 
business  systems  (DBSs).  The  DoD  released  interim  acquisition  guidance  for 
DBS  that  provided  program  managers  with  a  transitional  IT  acquisition  process 
until  the  new  IT  acquisition  process  could  be  developed  and  released  (Bellomo, 
2011).  The  DoD  would  later  release  a  report  entitled  A  New  Approach  for 
Delivering  Information  Capabilities  in  the  DoD,  which  provided  an  update  on  the 
progress  towards  development  of  the  new  IT  acquisition  process  as  well  as  some 
initial  implementation  guidelines.  In  2010,  then  Under  Secretary  of  Defense  for 
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Acquisition,  Technology,  and  Logistics  (USD[AT&L])  Mr.  Ashton  Carter  approved 
the  use  of  the  new  Business  Capability  Lifecycle  (BCL)  process  for  acquiring 
DBSs  as  part  of  DoD’s  implementation  of  the  agile  IT  acquisition  process 
(USD[AT&L],  2013).  However,  this  new  IT  acquisition  system  does  not  come 
without  potential  problems  and  shortfalls  as  will  be  explained  in  Chapter  IV. 

Gates’  reform  efforts,  which  were  carried  forward  by  his  successor,  former 
Secretary  of  Defense  Leon  Panetta  and  current  Secretary  Chuck  Hagel,  are 
continuing  to  play  out  today  but  beg  the  question  if  this  latest  attempt  at 
acquisition  reform  will  succeed  where  three  decades  of  efforts  have  seemingly 
failed.  The  long  history  of  acquisition  reforms  within  the  federal  government  and 
the  DoD  reflects  that  much  has  been  done  to  identify  the  problems,  implement 
solutions,  and  execute  reform  actions;  however,  most  of  these  reform  efforts 
appear  to  initiate  a  return  to  the  conclusion  that  more  reform  is  needed.  There  is 
a  reason  why  many  of  the  problems  that  have  existed  for  years  continue  to 
persist.  Furthermore,  there  is  a  reason  why  these  change  efforts  did  not  work  or 
resolve  the  problems.  The  history  of  reform  efforts  is  an  important  backdrop  to 
Chapter  V  topics  because  that  chapter  will  offer  insight  into  why  these  and  many 
reforms  efforts  do  not  succeed  or  lead  to  effective  change.  For  now,  it  is 
necessary  to  turn  our  attention  to  the  current  acquisition  process  and  how  it  has 
been  affected  by  these  latest  reform  efforts. 

B.  THE  CURRENT  IT  ACQUISITION  SYSTEMS 

1.  Types  of  Major  Automated  Information  Systems  Acquisition 
and  Acquisition  Models 

Before  discussing  the  current  IT  acquisition  systems,  it  is  important  to 
understand  the  types  of  Defense  business  systems  (DBSs)  and/or  major 
automated  information  systems  (MAIS)  acquisition  goals  the  DoD  seeks  to 
accomplish.  There  are  four  general  types  of  IT  acquisitions:  1)  application 
software  development  and  integration,  2)  commercial  off-the-shelf  (COTS) 
hardware  and  software  integration,  3)  integration  of  COTS  and  custom- 
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developed  capabilities,  and  4)  commercially  provided  IT  services  (DSB,  2009). 
Another  way  of  describing  these  four  general  types  of  IT  acquisitions,  as  well  as 
describing  categories  of  DBSs  is  through  the  use  of  the  terms  DoD-unique 
systems,  modified  and  integrated  COTS,  and  software  as  a  service  (SaaS). 

DoD-unique  systems,  modified  and  integrated  COTS,  and  software  as  a 
service  (SaaS)  encompass  what  the  DoD  seeks  to  procure  in  the  IT  acquisition 
process.  A  DoD-unique  system  is  required  when  existing  or  modified  commercial 
products  cannot  meet  end-user  requirements  (Gansler  &  Lucyshyn,  2012).  Thus, 
the  DoD  must  develop  its  own  unique  product  in  an  effort  to  fulfill  end-user 
requirements.  However,  there  is  a  downside  to  DoD-unique  products  in  that  a 
unique  system  or  application  generally  requires  a  longer  time  commitment  since 
the  product  is  not  available  on  the  commercial  market  (Gansler  &  Lucyshyn, 
2012).  DoD-unique  systems  are  regarded  as  the  least  efficient  way  to  acquire  an 
IT  system  due  to  this  downside. 

Commercial  off-the-shelf  (COTS)  IT  products  are  a  worthwhile  investment 
and  offer  the  greatest  benefit  to  the  DoD  although  they  cannot  meet  all  the  DoD’s 
requirements.  COTS  products  are  “as-is”  systems  and  applications  that  can  meet 
end-user  requirements  and  do  not  require  modification  or  integration  of  other 
components  prior  to  implementation  (Gansler  &  Lucyshyn,  2012).  Using  “as-is” 
COTS  products  allows  the  DoD  to  leverage  commercial  investments  and  take 
advantage  of  their  technological  innovation.  By  utilizing  COTS  products,  the  DoD 
significantly  reduces  research  and  developmental  time,  and  takes  advantage  of 
industry  best  practices  (Gansler  &  Lucyshyn,  2012).  However,  when  it  is 
essential  for  a  COTS  product  to  be  integrated  into  an  existing  system,  COTS 
products  often  require  modification.  Thus,  commercial  products  that  have  been 
modified  to  meet  DoD  requirements  are  referred  to  as  modified  COTS  products 
and  like  as-is  COTS  products,  developmental  time  is  reduced  compared  to  DoD- 
unique  systems.  To  further  meet  unique  end-user  requirements,  it  is  often 
necessary  to  integrate  both  DoD-unique  systems  and  COTS  systems  into  an 
existing  system.  The  integration  of  a  COTS  system  as  a  component  differs  from 
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modified  COTS  because  modified  COTS  are  obviously  modified  while  integration 
involves  the  use  of  a  COTS  system  as  a  component  within  an  integrated  system 
(Gansler&  Lucyshyn,  2012). 

Finally,  software  as  a  service  (SaaS)  is  a  software  delivery  method  where 
the  Internet  or  a  cloud  computing  service  provides  the  functionality  or  capability 
required.  SaaS  is  beginning  to  become  popular  within  the  DoD  as  evident  in  the 
DoD’s  201 1  release  of  the  Cloud  Computing  Strategy.  This  strategy  emphasizes 
cloud  computing  as  a  method  to  help  agencies  provide  highly  reliable,  innovative 
services  quickly,  despite  resource  constraints  (Kundra,  201 1). 

As  mentioned,  DoD-unique  systems,  COTS  products  both  modified  and 
integrated,  and  SaaS  are  the  types  of  IT  acquisitions  the  Department  currently 
seeks  to  acquire.  In  doing  so,  there  are  now  two  distinct  processes  that  are  used 
to  acquire  Defense  business  systems  and/or  major  automated  information 
systems  (MAIS):  the  traditional  Defense  acquisition  System  and  the  Business 
Capability  Lifecycle  (BCL)  model.  As  discussed  in  Chapter  II,  MAIS  comprised  of 
a  range  of  IT  systems  that  include  command  and  control  systems, 
communications  systems,  and  Defense  business  systems  (i.e.,  logistics  and 
financial  management  systems).  These  systems  are  intended  to  provide  the  DoD 
with  access  to  a  wide  range  of  information  in  order  to  effectively  organize,  plan, 
execute,  and  monitor  Defense  operations.  All  MAIS  programs  must  utilize  one  of 
two  acquisition  frameworks.  The  first  framework  is  the  traditional  Defense 
Acquisition  System  framework,  which  applies  to  all  DoD  IT  acquisition  programs 
except  business  system  modernization  programs  that  exceed  $1  million  in  total 
costs  as  indicated  in  DoD  5000.02  (USD[AT&L],  2008).  The  second  framework, 
the  Business  Capability  Lifecycle  (BCL),  is  relatively  new  as  it  was  released  in 
June  2011.  This  framework  applies  only  to  business  system  modernization 
programs  with  total  costs  exceeding  $1  million  (USD[AT&L],  2013). 
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2.  The  Traditional  Defense  Acquisition  System  Framework 

The  traditional  Defense  Acquisition  System  framework  is  outlined  in  DoD’s 
5000  Series  publications,  specifically  DoDD  5000.01  and  DoDI  5000.02.  The 
Defense  acquisition  management  system  framework  can  be  described  as  an 
overarching  process  that  integrates  three  interdependent  processes: 
requirements,  budgets,  and  procurements  (Gansler  &  Lucyshyn,  2012).  These 
three  interdependent  processes  work  both  independently  and  cooperatively  in  an 
effort  to  meet  IT  program  objectives.  All  three  can  be  described  in  the  three  major 
decision-support  systems  discussed  in  Chapter  II:  the  Joint  Capabilities 
Integration  and  Development  System  (JCIDS);  the  Defense  Acquisition  System; 
and  the  Planning,  Programming,  Budgeting  and  Execution  (PPBE)  process.  The 
product  or  system  requirements  are  defined  by  the  JCIDS,  which  also  provides 
acquisition  program  evaluation  criteria.  The  PPBE  process  determines  the 
budget  and  is  used  to  allocate  and  manage  financial  resources.  The  procurement 
process  is  essentially  the  Defense  acquisition  management  system  or 
framework.  This  framework  is  the  mechanism  through  which  the  Department 
develops  products  and  systems.  In  theory,  each  of  these  three  processes  is 
designed  to  work  in  a  coordinated,  efficient,  and  cost-effective  manner  to  deliver 
required  capabilities  to  the  DoD. 

The  Defense  acquisition  management  system  framework  provides  the 
steps  that  Major  Defense  Acquisition  Programs  (MDAPs)  must  take  as  they  are 
planned,  designed,  acquired,  deployed,  operated,  and  maintained  (GAO,  2013). 
The  framework  consists  of  five  program  lifecycle  phases  and  five  related  decision 
points  as  depicted  in  Figure  5.  The  five  decision  points  include  three  milestone 
decisions  at  milestones  A,  B,  and  C,  which  indicate  program  progression  or 
stage,  and  two  other  decisions  that  consist  of  the  materiel  development  decision 
and  the  full  deployment  decision  (GAO,  2013).  The  materiel  development 
decision  authorizes  officials  to  conduct  analyses  to  assess  the  potential  solutions 
that  can  satisfy  the  program’s  requirements,  and  the  full  deployment  decision 
authorizes  the  system  to  be  deployed  to  all  relevant  locations  after  limited  fielding 
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has  been  complete  (GAO,  2013).  For  programs  that  are  required  to  use  this 
framework,  the  milestone  decision  authority  (MDA)  will  either  be  the  Under 
Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics  (USD[AT&L]); 
the  DoD  component  head;  a  component  acquisition  executive  (CAE);  or  when 
authorized,  a  designee  (GAO,  2013). 
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Figure  5.  The  Traditional  Defense  Acquisition  Management  System 

(From  GAO,  2013) 


The  Defense  Acquisition  Framework  consists  of  the  following  phases  as  depicted 
in  Figure  5: 

•  Materiel  Solution  Analysis.  The  purpose  of  this  phase  is  to  assess 
the  potential  materiel  solutions  for  a  military  need;  to  refine  the 
initial  system  solution  (concept);  and  to  create  a  strategy  for 
acquiring  the  solution.  At  the  end  of  this  phase,  the  program 
reaches  Milestone  A,  where  a  decision  is  made  as  to  whether  or 
not  the  program  will  advance  to  the  next  phase. 

•  Technology  Development.  During  this  phase,  technologies  are 
developed,  matured,  and  tested  in  conjunction  with  the 
simultaneous  refinement  of  user  requirements.  A  decision  is  made 
at  the  end  of  this  phase  to  authorize  product  development  based  on 
well-defined  technology  and  a  reasonable  system  design  plan — 
referred  to  as  Milestone  B.  An  acquisition  program  baseline  (APB) 
is  first  established  at  the  Milestone  B  decision  point.  A  program’s 
first  APB  contains  the  original  lifecycle  cost  estimate,  schedule 
estimate,  and  performance  parameters  that  were  approved  for  that 
program  by  the  milestone  decision  authority.  The  first  APB  is 
established  after  the  program  has  assessed  the  viability  of  various 
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technologies  and  refined  user  requirements  to  identify  the  most 
appropriate  technology  solution  that  demonstrates  that  it  can  meet 
users’  needs.  By  the  completion  of  this  phase,  the  program  must 
have  mature  technology,  approved  requirements,  full  funding,  an 
acquisition  strategy,  and  the  APB.  Additionally,  the  type  of  contract 
that  will  be  used  to  acquire  the  system  must  be  specified.  The 
Milestone  B  decision  authorizes  entry  into  the  next  phase. 

•  Engineering  and  Manufacturing  Development.  The  purpose  of  this 
phase  is  to  develop  and  integrate  the  full  system,  make 
preparations  for  manufacturing,  and  demonstrate  through 
developer  testing  that  the  system  can  function  in  its  intended 
environment.  A  Milestone  C  decision  is  made  at  the  end  of  this 
phase  to  authorize  entry  of  the  system  into  the  production  and 
deployment  phase  or  into  limited  deployment  or  low-rate  initial 
production  (LRIP)  in  support  of  operational  testing. 

•  Production  and  Deployment.  During  this  phase,  the  system  is 
produced,  operationally  tested,  and  deployed.  At  this  point,  the 
system  achieves  an  operational  capability  that  satisfies  the  end- 
users  needs,  as  verified  through  independent  operational  testing 
and  evaluation,  and  is  implemented  at  all  applicable  locations. 

•  Operations  and  Support.  This  is  the  final  phase.  Program  personnel 
ensure  that  the  system  is  sustained  in  the  most  cost-effective 
manner  over  its  lifecycle.  (GAO,  2013) 

The  traditional  acquisition  system  framework  is  designed  to  translate 
mission  needs  or  requirements  into  stable,  affordable,  and  well-managed 
acquisition  programs  and  has  proven  relatively  successful  at  producing 
weapons  systems  and  larger  platforms  (Gansler  &  Lucyshyn,  2012).  Although 
this  linear  acquisition  process  is  based  on  the  development  of  hardware  systems 
(e.g.,  weapons  and  aircraft),  it  was  initially  intended  to  accommodate  the  needs 
of  all  DoD  programs  to  include  IT  (Gansler  &  Lucyshyn,  2012).  However,  the 
deficiencies  of  this  overall  process  make  this  framework  ill-suited  for  the 
development  of  IT-centric  systems  and  Defense  business  systems. 

The  traditional  Defense  Acquisition  Systems  framework  has  been 
described  as  a  highly  complex  mechanism  that  is  fragmented  in  its  operations. 
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As  it  relates  to  IT  under  this  framework,  attempts  to  accelerate  IT  development 
cycles  in  order  to  keep  pace  with  technical  innovation  only  serve  to  amplify  this 
fragmentation  (Report  by  the  Assessment  Panel  of  the  Defense  Acquisition 
Performance  Assessment  Project,  2006).  Not  only  is  the  framework  fragmented, 
but  also  its  phases  do  not  conform  well  with  information  technology  as  it  relates 
to  commercial  industry  best  practices  or  COTS  products.  For  instance,  the  first 
phase  in  the  acquisition  process  is  Phase  A,  which  is  intended  to  mature 
technology;  however,  information  technologies  in  the  commercial  sector  are 
largely  established  and  already  mature  so  this  action  is  not  necessary  (HASC, 
2010).  The  next  phase,  Phase  B,  is  intended  to  prepare  a  program  for 
production;  however,  information  technologies  are  not  produced  in  quantities 
while  being  developed  (HASC,  2010).  The  final  phase,  Phase  C,  is  the 
production  phase,  which  is  irrelevant  because  information  technology,  once 
again,  is  not  produced  in  quantity  (HASC,  2010).  To  exacerbate  these  milestone 
phase  issues,  the  time  between  the  start  of  a  program’s  analysis  phase  to 
Milestone  B  is  on  average  43  months  or  14  months  to  complete  the  analysis  of 
alternatives  and  29  months  to  complete  the  economic  analysis  (DSB,  2009). 
Furthermore,  it  has  taken  on  average  48  months  to  deliver  useful  functionality 
from  the  Milestone  B  decision,  which  has  required  40  months  for  development 
with  an  additional  5-8  months  for  operational  testing  and  evaluation  (DSB,  2009). 

With  this  being  the  case,  IT  acquisition  programs  have  suffered 
considerably.  Take,  for  example,  the  nine  DoD  enterprise  resource  planning 
(ERP)  programs,  which  are  being  acquired  to  replace  over  500  legacy  systems 
and  will  perform  business-related  tasks  (e.g.,  accounting  and  supply  chain 
management).  According  to  a  2010  GAO  report,  “six  of  the  nine  [DoD]  ERPs 
have  experienced  schedule  delays  ranging  from  2  to  12  years  and  five  have 
incurred  cost  increases  ranging  from  $530  million  to  $2.4  billion”  (GAO,  2010). 
One  of  the  nine  ERP  is  the  Navy  ERP,  which  has  experienced  a  schedule  delay 
of  2  years  (GAO,  2010).  The  GAO  produced  another  report  in  2013  as  directed 
by  the  National  Defense  Authorization  Act  (NDAA)  for  Fiscal  Year  2012  which 
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mandated  that  GAO  select  and  assess  DoD  MAIS  programs  annually  through 
March  2018  (GAO,  2013).  The  GAO  2013  report  stated: 

Of  the  14  selected  Department  of  Defense  (DoD)  major  automated 
information  system  (MAIS)  programs,  9  had  stayed  within  their 
planned  cost  estimates,  while  5  did  not  (with  cost  increases  ranging 
from  3  to  578  percent);  5  programs  remained  on  schedule,  while 
9  experienced  delays  (ranging  from  6  months  to  10  years);  and 
8  programs  met  their  system  performance  targets,  while  5  did  not 
fully  meet  their  targets,  and  1  did  not  have  system  performance 
data  available.  Looking  at  these  areas  collectively,  3  programs 
stayed  within  their  planned  cost  and  schedule  estimates  and  met 
their  system  performance  targets,  and  2  programs  experienced 
shortcomings  in  all  of  the  areas — cost,  schedule,  and  performance. 

(GAO,  2013) 

The  Navy  ERP  was  one  of  the  14  MAIS  programs  selected  for  review,  as  the 
Navy  ERP  remained  on  GAO’s  radar  as  a  failing  MAIS  acquisition  program.  The 
failures  of  the  traditional  Defense  acquisition  system  while  being  used  to  acquire 
the  Navy  ERP  were  significant  in  delaying  its  completion. 

The  Navy  ERP  is  currently  being  acquired  using  the  traditional  Defense 
Acquisition  System  framework.  The  procurement  process  began  in  2003  and  it  is 
still  in  the  acquisition  process  because  it  is  not  fully  deployed  as  of  yet  as 
depicted  in  Figure  6.  As  of  November  2012,  the  Navy  ERP  had  been  fully  fielded 
to  108  locations  and  72,000  users  but  the  program  has  been  working  to  stabilize 
the  system  in  order  to  achieve  full  deployment,  which  is  planned  for  August  2013 
(GAO,  2013).  Once  fully  deployed,  the  Navy  ERP  is  intended  to  replace 
segregated  legacy  systems  with  a  single  integrated  software  system  (GAO, 
2013).  This  new  system  will  provide  an  end-to-end  supply  chain  solution  for 
receiving,  processing,  and  fulfilling  requests  for  resources;  will  integrate  financial 
management,  workforce  management,  inventory  management,  and  material 
operations;  and  will  provide  a  rapid  response  to  logistical  needs  of  operating 
forces  (GAO,  2013). 
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Figure  6.  Navy  ERP  (From  GAO,  2013) 

As  mentioned,  the  Navy  ERP  experienced  significant  schedule  slippage 
that  exceeded  the  planned  schedule  by  more  than  2  years.  Delays  occurred  as  a 
result  of  several  issues  in  the  program  involving  requirements,  testing,  and 
system  development.  In  regard  to  requirements,  there  was  a  change  in  2009  to 
remove  certain  maintenance  requirements  from  the  ERP  that  were  perhaps 
unnecessary.  As  discussed  in  Chapter  II,  when  using  the  traditional  Defense 
acquisition  system,  the  requirements  definition  phase  has  been  problematic.  It 
appears  that  the  Navy  ERP  had  an  issue  with  “small-r”  requirements,  which 
again  are  the  more  detailed  requirements  or  information  associated  with  specific 
user  interfaces  and  utilities.  It  is  not  specified  why  the  Navy  ERP’s  maintenance 
requirement  was  removed,  but  it  is  clear  that  issues  involving  requirements  serve 
to  lengthen  the  IT  acquisition  cycle.  Another  issue  occurred  in  2011  regarding 
testing,  which  was  also  problematic  within  the  traditional  framework.  For 
instance,  a  substantial  number  of  system  deficiencies  were  identified  during 
system  development  and  initial  testing  of  a  supply  solution,  which  resulted  in  the 
program  failing  to  achieve  its  planned  full  deployment  decision  (GAO,  2013).  As 
discussed  in  Chapter  II,  testing  has  been  an  issue  in  the  IT  acquisition  process 
because  it  is  often  integrated  too  late  during  system  development.  Perhaps,  if 
testing  were  conducted  throughout  the  process,  the  issue  regarding  the  supply 
solution  would  not  have  caused  such  a  significant  delay,  if  any.  Also,  final 
operational  testing  and  evaluation  for  the  Navy  ERP  was  delayed  from  April  2012 
to  January  2013  due  to  the  need  for  additional  time  to  mitigate  system 

deficiencies  (GAO,  2013).  Once  again,  system  deficiencies  could  have  been 

63 


detected  and  mitigated  a  lot  sooner  if  the  acquisition  process  were 
accommodating  to  testing  early  and  often.  Lastly,  other  program  delays  were 
attributed  to  changes  that  were  implemented  based  on  lessons  learned  from  an 
earlier  deployment. 

Schedule  slippages  and  delays  in  delivering  IT  systems  have  been  the 
focus  of  this  study  but,  as  discussed  earlier,  schedule  delays  and  the  long 
acquisition  timelines  have  adverse  effects  on  both  cost  and  performance.  In 
regard  to  cost,  the  schedule  slippages  significantly  affected  the  Navy  ERP’s  initial 
lifecycle  cost  estimate.  In  fact,  program  officials  attributed  the  lifecycle  cost 
increases  to  schedule  slippages,  an  increase  in  demand  for  on-site  support  and 
stabilization  activities  during  system  deployments,  and  adding  requirements  to 
support  business  process  reengineering  and  improved  financial  management 
information  (GAO,  2013).  In  regard  to  performance,  these  schedule  slippages 
can  be  loosely  tied  to  performance  as  well.  For  example,  the  Navy  ERP  had  only 
partially  met  its  system  performance  measures  because  substantial  system 
deficiencies  remained.  In  December  2012,  program  officials  reported  that  the 
performance  measure  that  it  did  not  meet  may  not  be  related  to  the  Navy  ERP 
system  and  that  root  causes  would  be  further  identified  during  the  final 
operational  testing  and  evaluation  scheduled  to  begin  in  January  2013  (GAO, 
2013).  Originally,  the  Navy  ERP  testing  and  evaluation  phase  was  scheduled  to 
begin  in  April  2012,  nine  months  earlier,  but  due  to  schedule  slippages  it  did  not 
take  place.  If  the  schedule  had  been  maintained  to  allow  testing  and  evaluation 
to  occur  in  April  2012,  then  the  performance  measure  that  was  not  met  due  to  an 
unknown  problem  could  have  been  investigated  and  resolved  a  lot  sooner  in 
order  to  deliver  required  performance. 

Overall,  the  2013  GAO  report  highlights  the  significant  problems  among 
current  MAIS  programs  and  many  of  these  problems  are  the  same  old  problems 
that  have  plagued  the  entire  IT  acquisition  process  over  the  past  decade.  There 
have  been  a  number  of  assessments  conducted  by  many  groups  that  have 
determined  the  inadequacy  of  this  framework  as  it  relates  to  IT  acquisitions. 
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After  the  Defense  Science  Board  (DSB)  released  its  2009  report  indicating  that 
“16  percent  of  all  IT  projects  complete  on  time  and  on  budget,  31  percent  were 
cancelled  before  completion,  53  percent  were  late  and  over  budget,  and  of  those 
that  were  completed,  the  final  product  contained  only  61  percent  of  the  originally 
specified  features  10  years  ago,”  the  National  Defense  Authorization  Act  of  2010 
mandated  the  development  and  implementation  of  the  new  Business  Capability 
Lifecycle  (BCL)  acquisition  framework. 

3.  Business  Capability  Lifecycle  Framework 

The  DoD’s  goal  is  to  acquire  IT  systems  quickly  and  cost  effectively; 
however,  this  goal  has  been  rarely  achieved  due  to  the  deliberate  process  of  the 
DoD  traditional  acquisition  system.  Thus,  the  Business  Capability  Lifecycle 
framework  was  created  via  a  business  process  reengineering  (BPR)  effort  that 
was  aimed  at  making  improvements  by  elevating  efficiency  and  effectiveness  of 
the  end-to-end  acquisition  business  process.  The  Under  Secretary  of  Defense  for 
Acquisition,  Technology  &  Logistics  (USD[AT&Lj)  established  the  new  BCL  policy 
in  Directive-Type  Memorandum  (DTM)  11-009,  Acquisition  Policy  for  Defense 
Business  Systems,  which  sets  guidance  for  the  implementation  of  this  new 
framework.  Also,  the  Office  of  the  Deputy  Chief  Management  Officer  (ODMCO)  is 
integral  to  the  implementation  process,  as  this  office  leads  integration  and 
improvement  efforts  for  all  DoD  business  operations.  The  BCL  framework  was 
authorized  for  implementation  in  June  2011  and  was  last  updated  in  January 
2013.  BCL  policy  only  applies  to  DBS  modernization  programs  that  incur  a  total 
cost  over  $1 ,000,000  dollars.  For  programs  less  than  this  amount  or  for  programs 
that  are  non-DBS,  the  traditional  acquisition  system  still  applies. 

In  general,  the  Business  Capability  Lifecycle  (BCL)  framework  is  an 
“overarching  framework  for  the  planning,  design,  acquisition,  deployment, 
operations,  maintenance,  and  modernization  of  Defense  business  systems” 
(USD[AT&L],  2013).  BCL  facilitates  rapid  Defense  business  systems  and  major 
automated  information  systems  acquisition  and  deployment  by  providing  a 
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process  that  is  exclusively  tailored  to  the  unique  requirements  of  DBS  and  MAIS 
programs  (USD[AT&L],  2013).  BCL  takes  a  holistic  approach  to  IT  acquisition 
that  includes  doctrine,  organization,  training,  materiel,  leadership  and  education, 
personnel,  and  facilities  (DOTMLPF)  in  order  to  conduct  a  rigorous  analysis  of 
the  requirements  to  enable  rapid  delivery  of  business  capabilities  to  the 
warfighter  in  a  compressed  time  frame  (USD[AT&L],  2013).  The  BCL  framework 
has  been  set  as  mandatory  guidance  in  the  DTM  but  will  be  incorporated  into 
DoD  Instruction  (DoDI)  5000.02  later  this  year.  Also,  the  framework  is  viewed  as 
a  guideline  and  tailoring  that  is  consistent  with  statutes  and  sound  business 
practices  is  encouraged  (USD[AT&L],  2013). 

The  DoD  has  instituted  BCL  with  the  expressed  intent  to  address  the 
unique  challenges  of  IT  acquisition,  recognizing  that  the  traditional  acquisition 
system  is  not  agile  enough  to  meet  the  speed  at  which  new  IT  capabilities  are 
being  produced  in  the  commercial  sector.  BCL  recognizes  that  technology  rapidly 
evolves,  and,  consequently,  BCL  mandates  rapid  capability  development.  The 
BCL  framework  consolidates  the  requirements,  investment,  and  acquisition 
processes  under  a  single  governance  framework  and  provides  an  end-to-end 
process  that  is  intended  to  be  much  different  from  the  traditional  acquisition 
system  (USD[AT&L],  2013).  Furthermore,  BCL  provides  tiered  accountability 
while  delegating  authority  and  accountability  for  program  outcomes  and 
compliance  down  to  the  lowest  appropriate  levels,  which  has  been  a  problem 
under  the  traditional  system  (USD[AT&L],  2013).  The  BCL  model  is  based  on 
best  commercial  practices  and  is  more  outcome  oriented.  Ultimately,  the  BCL 
framework  is  designed  to  address  the  long-standing  problems  that  have  affected 
the  timely  delivery  of  IT  business  capabilities.  Specifically,  BCL  addresses 
problems  such  as  programs  lacking  well-defined,  strategically  linked 
requirements;  the  multiple  review  and  governance  bodies  that  are  redundant, 
delays  created  by  bureaucracy;  and  JCIDS  and  DoDI  5000.02  guidance  and 
procedures  which  are  primarily  designed  for  major  weapons  systems  acquisition 
that  have  taken  more  than  5  years  on  average. 
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The  BCL  process  seeks  to  employ  an  incremental  approach  to  IT 
acquisition  that  would  begin  with  an  approved  business  need  that  requires  a 
materiel  solution.  Then,  the  approved  materiel  solution  is  divided  into  discrete, 
fully  funded,  and  manageable  increments  in  order  to  facilitate  development  and 
implementation  of  the  DBS  (USD[AT&L],  2013).  Furthermore,  these  increments 
are  developed,  tested  and  evaluated,  produced,  deployed,  and  sustained  to  be 
useful  and  supportable  capabilities  in  an  operational  environment.  Also,  there 
can  be  multiple  releases  within  a  single  increment  or  multiple  increments  can  be 
approved  concurrently  if  funding,  approved  requirements,  and  the  appropriate 
entrance  and  exit  criteria  have  been  met  (USD[AT&L],  2013).  The  emphasis  here 
is  that  delivery  of  IT  capabilities  within  a  single  increment  must  be  based  on 
mature  technologies  and  funding  must  be  in  place.  Functional  capabilities  that 
are  not  supported  by  adequate  cost  estimates,  mature  technologies,  or  any  other 
reason  will  be  deferred  to  subsequent  program  increments  (USD[AT&L],  2013). 

The  BCL  framework  consists  of  seven  lifecycle  phases  and  five  decision 
points — milestones  A,  B,  and  C,  a  materiel  development  decision,  and  a  full 
deployment  decision  as  depicted  in  Figure  7.  Along  with  these  decision  points, 
there  are  seven  developmental  phases  in  the  BCL  framework,  one  of  which  is  a 
completely  new  concept  and  is  referred  to  as  the  Business  Capability  Definition, 
which  occurs  at  the  very  beginning  of  a  program. 
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Figure  7.  Basic  BCL  Framework  (From  GAO,  2013) 
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Additionally,  the  BCL  framework  comprises  three  distinct  stages:  Business 
Capability  Definition  (BCD),  Investment  Management  (IM),  and  Execution.  The 
Execution  stage  consists  of  the  remaining  phases  (e.g.,  Prototyping  Phase)  or 
the  actual  acquisition  portion  of  the  BCL  process.  In  total,  the  BCL  framework 
consists  of  the  following  processes: 

•  Business  Capability  Definition  (BCD).  The  purpose  of  this  phase  is 
to  analyze  a  perceived  business  problem  or  need,  capability  gap,  or 
opportunity  and  to  document  the  results  in  a  Problem  Statement  to 
inform  the  Investment  Review  Board  (IRB)  Chair  and  MDA 
decisions.  The  activities  performed  and  documentation  required  in 
the  BCD  phase  shall  be  used  in  lieu  of  the  Joint  Capabilities 
Integration  and  Development  System  (JCIDS). 

•  Investment  Management  (IM).  The  purpose  of  this  phase  is  to 
assess  potential  materiel  solutions  and  to  satisfy  the  phase-specific 
entrance  criteria  designated  by  the  MDA  for  the  next  milestone.  The 
entrance  criteria  for  this  phase  are  an  approved  Problem 
Statement,  Analysis  of  Alternatives  (AoA)  Study  Guidance,  and 
AoA  Study  Plan  sent  to  the  MDA. 

•  Prototyping.  The  purpose  of  this  phase  is  to  demonstrate  the 
capability  of  the  software  to  meet  business  process  requirements 
as  outlined  in  the  Business  Case.  Prototyping  includes  installing  IT 
in  a  relevant  environment  to  gain  the  knowledge  necessary  to  refine 
user  requirements  and  inform  APB  development.  The  entrance 
criteria  for  this  phase  are  completion  and  submission  of  a  Business 
Case  reflecting  the  AoA  results  and  the  proposed  materiel  solution, 
a  CAE-approved  Program  Charter,  full  funding  for  the  Prototyping 
Phase  as  certified  by  the  responsible  IRB  and  approved  by  the 
Defense  Business  System  Management  Committee  (DBSMC),  and 
compliance  with  the  MS  A  statutory  and  regulatory  requirements. 

•  Engineering  Development.  The  purpose  of  this  phase  is  to 
demonstrate  that  the  materiel  solution  for  the  increment  has  been 
designed,  configured,  developed,  and  tested  in  a  manner 
consistent  with  the  approved  Business  Case  and  Program  Charter, 
and  that  the  materiel  solution  is  ready  for  limited  fielding  and  testing 
in  an  operational  environment.  The  entrance  criteria  for  this  phase 
are  the  completion  of  the  specified  objectives  for  the  prototyping 
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phase,  if  conducted;  full  funding  of  the  program  or  program 
increment;  submission  of  a  draft  APB  and  an  updated  Business 
Case  and  Program  Charter;  and  compliance  with  the  MS  B 
statutory  and  regulatory  requirements. 

•  Limited  Fielding  Phase.  The  purpose  of  this  phase  is  to  limit  risk  by 
providing  the  capability  to  a  limited  number  of  users  and  testing  it  in 
an  operational  environment.  Operational  test  and  evaluation 
(OT&E)  shall  determine  the  operational  effectiveness  and  suitability 
of  the  system.  The  entrance  criteria  for  this  phase  are  completion  or 
satisfaction  of  the  objectives  of  the  Engineering  Development 
Phase;  the  Functional  Sponsor  or  end-user’s  determination  that  the 
capability  achieves  the  outcomes  specified  in  the  Business  Case; 
and  the  program’s  compliance  with  the  statutory  and  regulatory 
requirements. 

•  Full  Deployment  Phase.  The  purpose  of  this  phase  is  to  field  an 
increment  of  capability  for  operational  use  in  accordance  with  the 
Business  Case.  The  entrance  criteria  for  this  phase  are  completion 
of  Initial  Operational  Test  &  Evaluation  (IOT&E)  or  other  required 
testing;  declaration  of  initial  operational  capability  (IOC);  and 
satisfaction  of  the  DOTMLPF  solution  outlined  in  the  Business 
Case. 

•  Operations  and  Support  (O&S).  The  purpose  of  this  phase  is  to 
execute  a  support  program  that  meets  materiel  readiness  and 
operational  support  performance  requirements  and  sustains  the 
system  in  the  most  cost-effective  manner  over  its  total  lifecycle. 
Planning  for  this  phase  shall  begin  prior  to  program  initiation  and 
shall  be  summarized  in  the  Business  Case.  O&S  has  two  major 
efforts:  lifecycle  sustainment  and  disposal.  The  entrance  criteria  for 
this  phase  are  completion  and  submission  of  an  approved  Business 
Case,  satisfaction  of  any  conditions  imposed  by  the  MDA  at  the  Full 
Deployment  Decision  (FDD),  and  the  Functional  Sponsor’s  written 
declaration  that  the  system  has  achieved  FD,  as  defined  in  the 
Business  Case.  (USD[AT&L],  2013) 

To  meet  the  demand  of  rapid  development,  the  BCL  is  designed  to 
execute  programs  quicker  than  has  been  the  case  using  the  traditional 
acquisition  system.  For  instance,  the  BCL  process  is  set  up  to  allow  no  more 
than  12  months  between  the  Materiel  Development  Decision  (MDD)  and  MS  A, 
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no  more  than  12  months  between  the  initial  contract  and  MS  B,  and  no  more 
than  18  months  between  contract  or  option  award  and  the  Full  Deployment 
Decision  (FDD)  (GAO,  2013).  The  final  decision  will  be  the  FDD,  which  will  be 
made  by  the  MDA  authorizing  an  increment  of  the  program  to  deploy  for 
operational  use. 

For  DBS  programs  that  are  MAIS  using  the  BCL  incremental  acquisition 
approach,  all  functional  capabilities  associated  with  each  increment  will  reflect 
the  Acquisition  Program  Baseline  (APB)  or  cost,  performance,  and  schedule 
goals  and  must  be  achievable  within  5  years  from  when  funds  were  first  obligated 
(GAO,  2013).  For  all  DBS  that  are  not  MAIS,  these  programs  must  achieve  Initial 
Operating  Capability  (IOC)  within  a  5-year  period  from  Milestone  (MS)  A  (GAO, 
2013).  Ultimately,  the  Milestone  Decision  Authority  (MDA)  will  not  grant  a  MS  A 
decision  if  IOC  cannot  be  achieved  within  5  years;  and  in  no  event  will  a  Full 
Deployment  Decisions  (FDD)  occur  later  than  5  years  from  when  program  funds 
were  first  obligated. 

The  first  program  to  achieve  an  acquisition  decision  under  the  BCL 
framework  was  a  struggling  Air  Force  financial  management  program  called 
Defense  Enterprise  Accounting  and  Management  System  (DEAMS)  (Information 
Technology  and  Cyber  Operations,  2013).  As  depicted  in  Figure  8,  DEAMS  was 
initiated  in  2003  and  development  continues  today.  Due  to  issues  in  the 
acquisition  process,  which  utilized  the  traditional  acquisition  framework,  DEAMS 
transitioned  to  the  BCL  framework  in  February  2012  (GAO,  2013).  DEAMS 
Increment  1  was  the  first  IT  developmental  process  to  utilize  the  BCL  framework 
and  the  development  process  is  currently  underway.  Increment  1  was  developed 
to  provide  60  percent  of  the  Air  Force  with  the  entire  spectrum  of  financial 
management  capabilities  and  is  also  intended  to  be  a  key  component  of  the 
DoD’s  plan  for  achieving  fully  auditable  financial  statements  by  2017  as  required 
by  the  National  Defense  Authorization  Act  for  fiscal  year  2010  (GAO,  2013). 
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First  acquisition  program  baseline  as  of  February  2012 


Latest  schedule  as  of  September  2012 
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Figure  8.  Prior  to  Milestone  B,  the  program  was  complying  with  the 
traditional  acquisition  framework.  Following  Milestone  B  in 
February  2012,  the  program  began  complying  with  the  BCL  model. 

(From  GAO,  2013) 


Although  the  program  had  been  struggling  under  the  traditional  acquisition 
system,  in  2007  and  2010,  the  Air  Force  began  demonstrating  some  capabilities 
provided  by  DEAMS  (GAO,  2013).  However,  due  to  schedule  delays  experienced 
in  2010,  the  program  underwent  a  critical  change.  This  critical  change  resulted  in 
a  restructuring  of  the  development  of  the  program  from  two  major  releases  to 
four  major  releases.  Also,  in  2012  under  the  BCL  framework,  the  DEAMS 
program  was  restructured  for  a  second  time  to  include  six  major  releases  that  will 
be  deployed  incrementally  beginning  with  Increment  1  (GAO,  2013). 

Since  establishing  its  first  acquisition  program  baseline  (APB),  DEAMS 
had  not  experienced  a  schedule  delay;  however,  the  program  experienced  a 
critical  delay  in  establishing  this  first  APB  (GAO,  2013).  Once  again,  the  program 
began  in  2003  and  the  first  APB  was  not  established  until  nearly  a  decade  later  in 
February  2012.  Essentially,  the  acquisition  process  had  been  underway  for 
almost  10  years  before  it  developed  a  robust  estimate  for  how  long  it  was  going 
to  take  to  be  developed  and  implemented  (GAO,  2013).  Some  of  the  schedule 
delays  were  attributed  to  the  complexity  of  reengineering  business  processes 
and  design  issues.  Also,  evolving  requirements  and  testing  issues  served  to 
delay  the  schedule,  which,  of  course,  have  been  identified  problems  within  the 
traditional  acquisition  system. 


71 


Although  the  BCL  framework  was  authorized  for  use  in  2010, 
implementation  of  the  framework  has  been  slow  as  the  DEAMS  program  is  one 
of  only  a  few  programs  currently  using  BCL.  However,  according  to  the  Deputy 
Chief  Management  Officer  (DCMO),  Ms.  Elizabeth  McGrath,  the  DoD  is  in  the 
process  of  transitioning  several  major  IT  programs  to  the  BCL  framework 
(Information  Technology  and  Cyber  Operations,  2013).  Since  the  BCL  framework 
is  relatively  new  and  implementation  of  this  acquisition  strategy  has  been  slow, 
there  is  little  to  no  data  on  the  success  rate  or  proof  of  concept.  However,  the 
potential  benefits  of  BCL  have  been  articulated  and  many  within  the  DoD  stand 
behind  this  new  acquisition  strategy,  especially  as  it  relates  to  DEAMS. 
According  to  the  DCMO,  “through  the  use  of  this  [BCL]  approach,  DEAMS  has 
integrated  traditionally  stove-piped  processes  and  enabled  tight  integration 
between  the  functional  sponsor  [or  end  user]  and  the  program  office”  (Information 
Technology  and  Cyber  Operations,  2013).  But,  again,  there  is  no  conclusive 
evidence  or  data,  as  of  yet,  to  suggest  that  the  BCL  framework  will  resolve  the 
systemic  problems  that  have  caused  major  delays  in  acquiring  IT  systems  within 
the  DoD.  With  this  being  the  case,  Chapter  IV  will  take  a  closer  look  at  the  BCL 
solution  and  that  of  others  who  have  recommended  solutions  in  order  to  assess 
the  likelihood  of  success  in  fixing  the  DoD’s  IT  acquisition  system. 
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IV.  BUSINESS  CAPABILITY  LIFECYCLE:  POTENTIAL 
BENEFITS,  SHORTFALLS,  PROBLEMS,  AND  OTHER 

SOLUTIONS 


A.  POTENTIAL  BENEFITS  OF  BCL 

The  premise  of  BCL  is  to  provide  an  acquisition  process  for  information 
technology  that  is  based  on  successful  commercial  practices  for  the  rapid 
acquisition  and  continuous  upgrade  and  improvement  of  IT  capabilities. 
Furthermore,  the  process  is  designed  to  be  agile  in  order  to  deliver  meaningful 
increments  of  capability  in  a  shorter  time  span,  ideally  12-18  months  or  fewer 
(see  Figure  9). 


From  Contract/Option  award 


Figure  9.  BCL  Iterative  Incremental  Process  (From  USD[AT&L],  2013) 

There  are  several  potential  benefits  of  using  the  BCL  framework.  First,  the 
BCL  framework  is  tailored  for  business  systems  not  for  weapons  platforms.  Also, 
the  framework  is  more  business  oriented  and  avoids  issues  such  as 
implementing  solutions  without  fully  understanding  business  needs.  Second,  BCL 
consolidates  traditional  requirements,  investment,  and  acquisition  processes 
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under  a  single  governance  structure  (e.g.,  Investment  Review  Board,  or  IRB). 
The  establishment  of  the  IRB  addresses  the  oversight  and  governance  issues 
that  were  experienced  under  the  traditional  acquisition  system.  Third,  the  BCL  is 
a  more  agile  and  flexible  process  that  can  be  tailored  to  specific  needs.  Fourth, 
there  is  a  focus  on  implementation  and  not  on  documentation.  BCL  minimizes  the 
paperwork  that  has  served  to  slow  down  the  IT  acquisition  process.  BCL’s  core 
documents  are  the  Business  Case  and  the  Program  Charter.  The  Business  Case 
provides  an  integrated,  executive-level  justification  for  the  recommended 
approach  to  solving  the  defined  problem,  while  the  Program  Charter  documents 
the  managerial  methods,  responsibilities,  and  governance  needed  to  successfully 
execute  the  program  (Office  of  the  Deputy  Chief  Management  Office,  2012). 
Also,  the  Business  Case  is  the  only  document  used  for  the  approval  process. 
Essentially,  these  two  documents  integrate,  summarize,  and/or  replace  content 
that  had  been  used  under  the  traditional  acquisition  system  for  making  executive- 
level  decisions  (BCL,  2012).  Lastly,  the  BCL  framework  can  potentially  offer 
greater  transparency  and  visibility,  which  will  enable  senior  decision  makers  to 
affect  outcomes  (Office  of  the  Deputy  Chief  Management  Office,  2012). 

B.  BCL  SHORTFALLS,  PROBLEMS,  AND  POTENTIAL  PROBLEMS 

When  the  BCL  framework  was  first  introduced  in  June  2011,  there  was 
much  optimism  that  significant  improvements  were  on  the  way;  however,  this 
optimism  quickly  faded  as  efforts  to  further  define  this  new  IT  acquisition  process 
began  to  stall  (Gilligan,  2012).  Progress  began  to  stall  as  the  result  of  significant 
impacts  on  various  DoD  processes  that  were  created  by  proposed  funding 
changes  or  the  lack  thereof,  program  implementation,  and  a  shift  to  a  portfolio- 
based  construct  across  requirements  (Gilligan,  2012).  As  discussions  on  these 
issues  created  gridlock  among  many  acquisition  executives  and  stakeholders, 
other  efforts  to  further  define  the  BCL  process  were  also  stymied.  To  further 
exacerbate  the  situation,  over  the  past  2  years,  IT  acquisition  reform  efforts  have 
been  less  of  a  priority  for  the  DoD  due  to  fiscal  concerns  related  to  reductions  in 

the  Defense  budget.  Nevertheless,  the  DoD  remains  committed  to  the  new  BCL 
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process,  as  continual  improvements  in  the  IT  acquisition  process  are  planned  in 
revisions  to  the  DoD’s  5000  series  acquisition  directives  (Gilligan,  2012). 

For  now,  the  DTM  continues  to  set  guidance  for  the  BCL  and  the 
acquisition  of  DBS  programs.  As  stated  in  the  BCL  implementation  guidance,  the 
new  BCL  framework  is  a  “first  step”  at  streamlining  the  acquisition  process  for 
business  systems  (DoD,  2010).  In  fact,  BCL  is  still  considered  to  be  within  its 
pilot  phase  as  it  is  still  awaiting  official  indoctrination  into  DoDI  5000.02.  More 
importantly,  the  BCL  model  is  described  as  a  mandatory  guideline  but  tailoring 
consistent  with  statute  and  sound  business  practice  is  encouraged  (USD[AT&L], 
2013).  Like  any  framework,  BCL  is  an  imperfect  model  of  reality,  but  it  is  useful  in 
addressing  many  of  the  issues  that  exist  within  the  IT  acquisition  system. 
Essentially,  the  problems  addressed  in  Chapter  II  regarding  the  misapplication  of 
the  traditional  acquisition  framework  to  IT  acquisition,  legislative  and  oversight 
issues,  and  requirements,  appear  to  be  addressed  in  the  new  BCL  framework,  at 
least  in  theory  because  again,  there  is  no  data  as  of  yet  on  the  success  of  the 
process. 

Although  certain  problems  are  addressed,  there  still  exist  other  problems, 
potential  problems,  and  shortfalls  within  the  BCL  process.  Due  to  BCL  being  an 
imperfect  solution,  as  recommended  tailoring  implies,  there  remain  issues 
regarding  its  limited  application,  the  acquisition  funding  process,  program  testing 
and  evaluation,  and  acquisition  workforce  concerns  and  management  issues  that 
need  to  be  further  addressed.  Also,  potential  problems  exist  in  the  timelines 
offered  by  the  BCL  framework  and  the  promise  of  a  rapid  acquisition  process, 
which,  again,  has  not  been  validated.  Another  potential  issue  exists  in  the 
structure  or  process  of  the  BCL  framework  and  its  resemblance  to  the  traditional 
acquisition  framework.  These  issues  will  be  further  discussed  in  the  next  three 
sections. 
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1. 


BCL  Framework  Similarities  to  the  Traditional  Acquisition 
Framework 


A  potential  problem  in  the  BCL  framework  is  that  this  new  framework  may 
not  produce  the  improvements  predicted  because  it  is  not  remarkably  different 
from  the  traditional  acquisition  framework.  Fundamentally,  the  BCL  was  designed 
to  be  different  from  the  traditional  acquisition  system,  but  compositionally  it  is 
very  similar.  For  instance,  there  are  seven  lifecycle  phases  and  five  decision 
points  (Milestones  A,  B,  and  C,  a  materiel  development  decision,  and  a  full 
deployment  decision)  in  the  BCL  process.  Along  with  the  five  decision  points,  six 
of  the  seven  developmental  phases  are  consistent  with  or  similar  to  the 
traditional  Defense  Acquisition  System  framework  in  regard  to  the  traditional 
framework’s  five  phases.  Moreover,  one  phase  (production  and  deployment)  in 
the  traditional  Defense  acquisition  system  framework  corresponds  to  two  phases 
(limited  fielding  and  full  deployment)  in  the  BCL  framework  (USD[AT&L],  2013). 
The  only  significant  differences  between  the  two  frameworks  are  the  BCL’s 
Business  Capability  Definition  phase  at  the  start  of  a  program  and  the  multiple 
developmental  iterations  and  their  associated  timelines.  This  similarity  to  the 
traditional  framework  begs  the  question  whether  the  new  framework  will  bring 
about  significant  changes  or  produce  the  same  stagnation  that  has  plagued  IT 
acquisition  in  the  past.  With  no  progress  data  available  thus  far,  it  is  too  early  to 
tell  if  this  new  framework  will  yield  the  predicted  improvements  in  speed,  cost, 
and  effectiveness  of  the  IT  acquisition  process. 

An  argument  can  be  made  that  the  iterative  incremental  aspect  of  the  BCL 
process  will  be  the  difference  maker;  however,  this  concept  was  not  recently 
created  but  has  been  an  aspect  of  evolutionary  acquisition  since  its  inception. 
Moreover,  the  iterative  incremental  development  ideas,  as  well  as  the  BCL 
tenets,  are  not  new  concepts  but  have  been  around  for  several  years.  The  roots 
of  iterative,  incremental  development  (I ID)  methods  can  be  traced  back  many 
years.  For  instance,  in  2002  the  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics  issued  a  memorandum  setting  forth  a  model  based  on 
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multiple  delivered  increments  and  multiple  spiral  cycles  within  each  delivered 
increment  (NRC,  2010).  Furthermore,  the  basic  framework  for  BCL  was 
recommended  in  the  2009  Defense  Science  Board  report.  Although  it  was  not 
named  the  “Business  Capability  Lifecycle,”  the  basic  elements  (i.e. ,  iterative 
development)  were  included  in  the  report  as  a  recommendation  for  a  new  IT 
acquisition  system. 

2.  BCL’s  Limited  Application 

One  BCL  shortfall  is  that  it  is  limited  in  its  application.  While  the  BCL 
process  is  applicable  across  the  DoD  IT  Enterprise,  the  process  does  not  apply 
to  all  categories  of  systems  across  the  IT  spectrum.  In  fact,  the  BCL  process  is 
applicable  only  to  systems  such  as  networked  IT  systems  (e.g.,  command  and 
control  and  business  systems);  however,  IT  hardware  requiring  unique 
development  and  requisite  production  decisions  will  not  use  the  BCL  process 
(Bellomo,  201 1).  In  other  words,  IT  projects  employing  the  new  BCL  process  will 
not  design  unique  hardware  or  conduct  technology  development.  In  fact,  IT 
projects  requiring  those  activities  will  use  the  traditional  DoD  acquisition  system 
in  an  effort  to  ensure  that  appropriate  focus  remains  on  designing  and  developing 
the  unique  hardware  (Bellomo,  2011).  Moreover,  business  system  modernization 
programs  meeting  a  certain  criteria  (i.e.,  total  cost  over  $1,000,000)  are  required 
to  use  the  BCL  framework;  however,  for  projects  less  than  one  million  dollars, 
those  projects  will  have  to  revert  once  again  to  the  traditional  acquisition  system. 
Essentially,  the  BCL  process  does  not  apply  to  or  attempt  to  solve  IT  acquisitions 
problems  for  all  IT  systems. 

3.  BCL  Timeline  Concerns 

Another  shortfall  is  that  the  BCL  timelines,  albeit  incremental  and  shorter, 
are  still  too  long  when  all  increments  are  combined  to  complete  a  program  in  its 
entirety  and  deliver  capabilities  to  the  end  users.  As  stated  in  the  DTM,  when  a 
Major  Automated  Information  System  (MAIS)  DBS  employs  the  BCL  or 
incremental  approach,  all  functional  capabilities  associated  with  a  given 
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increment  must  be  achievable  within  5  years  from  when  funds  were  first 
obligated  (DoD,  2010).  Also,  all  DBS  programs  that  are  not  MAIS  must  achieve 
Initial  Operating  Capability  (IOC)  within  5  years  from  Milestone  A,  which 
potentially  means  more  time  will  be  spent  before  capabilities  are  matured  and 
into  the  hands  of  end  users.  The  fact  is  that  some  IT  projects  are  likely  to  take 
the  full  5-year  period  based  on  project  requirements  or  even  due  to  the  allowance 
of  that  specific  amount  of  time. 

Five  years  is  an  inordinate  amount  of  time  for  an  IT  program  to  reach  IOC 
or  to  be  provided  to  the  end  user,  especially  if  a  system  needs  to  fulfill  time- 
critical  operational  requirements.  For  instance,  time-critical  operational 
requirements  are  extremely  important  in  regard  to  cyber  security.  Moreover, 
identifying  an  agile  and  adaptable  acquisition  process  that  can  field  new  IT 
capabilities  and  services  in  relatively  short  and  responsive  time  frames  in  order  to 
counter  or  prevent  cyber  threats  is  a  pressing  issue  for  the  U.S.  Navy.  The  U.S. 
Navy’s  Program  Manager,  Warfare  (PMW)  130,  an  office  in  the  Navy’s  Program 
Executive  Office  for  Command,  Control,  Communications,  Computers,  and 
Intelligence  (C4I),  is  focused  on  rapidly  fielding  innovative  IT  capabilities  in  order 
to  secure  the  cyber  domain,  assure  end-to-end  information,  and  enable  decision 
superiority  (Porche  et  al.,  2012).  According  to  a  2012  study  conducted  by  the 
Research  and  Development  (RAND)  corporation, 

[PMW]  requires  an  acquisition  and  fielding  cycle  that  can  deliver 
hardware  security  products  within  12-18  months,  software  security 
products  within  six  to  12  months,  and  incremental  development  for 
both  hardware  and  software  every  three  months.  These  time 
frames  are  far  shorter  than  the  traditional  acquisition  cycle  time, 
which  can  be  36  months  from  concept  approval  to  initial  operational 
capability  or  eight  to  10  years  for  full  operational  capability.  (Porche 
etal.,  2012) 

This  statement  is  mostly  in  the  context  of  the  traditional  acquisition 
system;  however,  it  applies  to  the  BCL  process  as  well.  According  to  PMW,  the 
Navy  would  like  to  follow  the  BCL’s  iterative  and  incremental  development 
process,  but  it  is  apparent  that  the  BCL  offerings  do  not  met  the  desired  timelines 
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(i.e.,  incremental  development  for  both  hardware  and  software  every  three 
months)  in  order  to  address  emerging  cyber  threats  (Porche  et  al. ,  2012). 
Consequently,  the  2012  RAND  study  sought  to  identify  ways  to  accelerate  or 
bypass  the  acquisition  process  in  response  to  the  unique  demands  of  PMW 
information  technology  and  cyber  programs.  Ultimately,  RAND  recommended  a 
distinct  acquisition  system  for  emerging  needs  that  could  be  handled  through  a 
separate  process  and  budget  (Porche  et  al.,  2012). 

Another  potential  BCL  timeline  issue  that  can  create  delays  and 
undermine  the  intent  of  the  BCL  process  is  a  failure  to  strictly  adhere  to  the 
iteration  time-box  or  the  deadline-driven  approach  to  system  development.  As 
described  in  Chapter  12  of  the  Defense  Acquisition  University  (DAU)  website,  the 
timelines  for  the  phases  of  BCL  must  be  taken  into  consideration  during  program 
planning,  scoping,  and  Business  Case  development  because  any  violations  of 
these  timelines  require  revalidation  of  the  Business  Case  that  can  potentially 
slow  down  the  delivery  of  capability  to  the  user  (DAU,  2012).  Table  1  outlines 
BCL  timelines  that  may  be  subject  to  delay  if  not  strictly  adhered  to,  whether  it  be 
for  a  legitimate  reason  or  not. 


Decision  Period 

Time  Allotted 

Materiel  Development  Decision  (MDD)  to  Milestone 
[MS)  A 

12  months 

MS  A  to  IOC* 

Within  5  years 

MS  A  to  Full  Deployment  Decision  (FDD) 

Within  5  years  (or  if  no  MS  A,  from  when  the 

Dreferred  alternative  was  selected  by  the  MDA) 

MS  A  (contract  /  option  award)  to  MS  B 

12  months  or  less*** 

MP**  (contract  /  option  award)  to  MS  B 

12  months  or  less*** 

MS  B  (contract  /  option  award)  to  FDD 

18  months  or  less*** 

Table  1 .  BCL  Timelines  (From  “DBS-specific  Criteria,”  2012,  June  5) 
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Also,  another  timing  issue  involves  the  Business  Capability  Definition 
(BCD)  Phase  because  there  is  no  set  time  limit  for  this  phase  to  be  completed. 
As  discussed  in  Chapter  III,  the  BCD  phase  is  conducted  at  the  very  beginning  of 
the  process  and  consists  of  an  analysis  of  a  perceived  business  problem  or 
capability  gap  and  is  an  important  first  step  as  the  new  framework  relies  heavily 
on  this  phase  being  done  correctly.  But  also,  the  BCL  timeline  depends  on  the 
Business  Definition  Phase  being  done  in  an  appropriate  amount  of  time  that  is 
consistent  with  the  goal  of  timely  acquisition. 

Timing  is  key  for  the  BCL  process  to  work  effectively  and  this  process 
depends  on  the  time-boxing  or  a  deadline-driven  approach.  In  using  the  time-box 
method,  work  items  can  slip  from  one  iteration  to  the  next,  but  iterations  are 
completed  according  to  schedule,  thus  affording  the  opportunity  to  quickly 
identify  erroneous  estimates  of  the  time  required  to  complete  deliverables  and 
ensuring  continuous  user  input  regarding  priorities  (NRC,  2010).  Although 
identifying  erroneous  time  estimates  and  receiving  user  feedback  is  of  value,  the 
fact  is  that  when  work  items  are  allowed  to  slip  from  one  iteration  to  the  next 
iteration,  so  do  capabilities.  Also,  according  to  the  DTM,  functional  capabilities 
that  are  not  supported  by  adequate  cost  estimates,  mature  technologies,  or 
otherwise  not  ready  will  be  deferred  to  subsequent  program  increments 
(USD[AT&L],  2013).  This  deference  or  allowing  of  work  items  to  slip  will 
inevitably  create  delays  in  capabilities  being  delivered  to  end  users. 

There  are  plenty  of  advantages  to  the  incremental  development  concept, 
which  is  considered  a  commercial  best  practice;  however,  one  disadvantage  or 
drawback  is  that  the  needed  capability  may  not  be  acquired  until  much  later  in 
the  process  or  maybe  even  acquired  at  the  tail  end,  which  is  at  the  5-year  mark 
in  the  case  of  the  BCL  process.  Essentially,  the  BCL  incremental  process  solves 
the  capability  gap  problem  a  little  bit  at  a  time  or  piecemeal,  but  when  done  over 
a  5-year  period,  it  is  not  much  different  than  a  lengthy  acquisition  process  solving 
the  entire  problem  over  the  same  time  span,  except  for  maybe  users  getting  an 
opportunity  to  have  some  functionality  in  hand  (e.g.,  prototypes).  According  to  the 
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Deputy  Chief  Management  Officer  Elizabeth  McGrath  (2011)  in  a  HASC 
committee  on  improving  management  and  acquisition  of  IT  in  DoD,  “[we  will 
group]  capabilities  such  that  they  are  delivered  in  a  spiral  fashion  and  not  try  and 
solve  the  entire  issue  at  the  get-go”  (Improving  Management  and  Acquisition  of 
Information  Technology  Systems  in  the  Department  of  Defense,  2011).  Solving 
part  of  the  problem  still  leaves  a  problem  that  can  potentially  linger  for  years. 
Also,  delivering  some  capability  and  then  adding  to  it  in  future  iterations  in  order 
to  make  a  system  more  effective  in  the  long  run  begs  the  question  of  whether  this 
method  will  provide  enough  capability  in  a  timely  manner  or  when  it  is  needed. 
The  iterative  incremental  method  is,  indeed,  a  proven  technique  as  it  is  a 
commercial  best  practice;  however,  the  5-year  period  provided  to  execute  this 
process  does  not  work  well  enough  in  every  scenario,  especially  in  the  case  of 
the  U.S.  Navy’s  cyber  threat  requirements. 

Overall,  the  BCL  process  appears  to  continue  to  allow  too  much  time  to  be 
spent  acquiring  a  system  considering  that  technology  advances  every  18 
months.  It  does  not  seem  practical  for  the  DoD  to  ever  keep  exact  pace  with  the 
advancements  in  technology  given  its  bureaucracy;  however,  given  commercial 
industry  practices,  it  is  practical  that  the  DoD  can  do  better  than  what  the  BCL 
framework  currently  offers.  In  fact,  there  are  other  proposed  solutions  to  the 
problems  identified  in  Chapter  II  that  will  be  discussed  in  the  next  section. 

C.  OTHER  SOLUTIONS  AND  FRAMEWORKS 

Various  studies  of  the  DoD’s  IT  acquisition  process  have  been  undertaken 
in  the  past  few  years  in  an  effort  to  propose  solutions  to  improve  the  overall 
effectiveness  and  efficiency  of  the  IT  acquisition  process.  Many  of  these  studies 
propose  models  or  frameworks  that  are  designed  to  facilitate  a  more  timely 
acquisition  process.  The  following  three  frameworks,  proposed  by  three  separate 
entities,  offer  similar  solutions  similar  to  the  BCL  process;  however,  each  one 
provides  additional  methodologies  and  detail  that  can  produce  shorter  timelines. 
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1. 


Two  Models  for  IT  Acquisition  for  Software  and  Hardware 
Development 


In  November  2009,  approximately  7  months  after  the  Defense  Science 
Board  (DSB)  released  its  report  on  the  failures  of  the  traditional  IT  acquisition 
system,  the  Defense  Information  Systems  Agency  (DISA)  requested  that  the 
National  Research  Council  (NRC)  conduct  an  assessment  of  the  efficacy  of  the 
DoD’s  acquisition  and  test  and  evaluation  (T&E)  processes  as  applied  to  IT 
(NRC,  2010).  In  response,  the  NRC  formed  a  committee  of  IT  systems 
acquisition  and  T&E  experts;  commercial  software  developers,  and  software 
engineers,  computer  scientists,  and  other  academic  researchers  that  was  tasked 
with  the  following: 

•  Evaluate  applicable  legislative  requirements 

•  Examine  the  processes  and  capabilities  of  the  commercial  IT  sector 

•  Examine  the  DoD’s  concepts  for  systems  engineering  and  testing  in 

virtual  environments 

•  Examine  the  DoD  acquisition  environment 

•  Recommend  how  to  improve  the  acquisition,  systems  engineering, 
and  T&E  processes  to  achieve  the  DoD’s  network-centric  goals. 
(NRC,  2010) 

To  complete  these  tasks,  the  committee  reviewed  IT  acquisition  documents 
concerning  the  process,  held  briefings  from  commercial  and  military  experts  in  IT 
systems  acquisition,  and  held  internal  deliberations  among  committee  members 
to  determine  issues  and  recommend  solutions.  Like  the  DSB  report  and  many 
other  studies  that  have  recommended  reforms  to  the  Defense  acquisition 
system’s  processes  and  rules  that  govern  the  development,  procurement, 
testing,  and  fielding  of  new  capabilities,  the  committee  concluded  that  there  is  a 
need  for  a  unique  acquisition  process  for  IT  (NRC,  2010).  Furthermore,  the 
committee  reached  the  same  fundamental  conclusion  of  other  studies  but  added 
another  dimension  in  defining  differing  types  of  IT  systems  and  suggested  an 
acquisition  process  for  each.  Thus,  one  of  the  most  significant  recommendations 
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was  the  NRC’s  proposal  of  two  different  acquisition  methods,  one  for  hardware 
and  one  for  software  acquisition. 

For  software  acquisition  programs,  the  model  is  referred  to  as  Software 
Development  and  Commercial  off-the-shelf  (COTS)  Integration  (SDCI) 
framework.  SDCI  was  designed  for  IT  programs  that  are  focused  on  the 
development  of  new  software  to  provide  new  functionality  or  to  integrate 
commercial  off-the-shelf  (COTS)  components  (NRC,  2010).  The  hardware  model 
is  referred  to  as  COTS  hardware,  software,  and  services  (CHSS)  framework. 
CHSS  was  designed  for  the  acquisition  of  COTS  IT  hardware,  software,  or 
services  to  exploit  commercially  available  products  and  services  without 
modification  to  meet  DoD  needs,  although  modification  to  meet  environmental 
requirements  in  a  deployed  environment  can  also  be  addressed  in  this  category 
of  programs  (NRC,  2010).  Both  SDCI  and  CHSS  programs  are  based  in 
commercial  best  practices  and  are  especially  suitable  for  acquiring  IT  systems 
that  support  DoD  information  enterprise  requirements  (NRC,  2010). 

Within  IT  development,  there  are  two  basic  types  of  IT  developmental 
processes:  hardware  and  software.  Given  their  distinct  nature,  each  requires 
different  developmental  processes.  For  instance  in  software,  the  number  of  lines 
of  executable  code  is  increasing  drastically,  which  further  exacerbate  the 
challenges  of  IT  development  (HASC,  2010).  Moreover,  software  projects  are 
more  difficult  to  manage  than  hardware  projects  for  a  few  reasons:  1 )  software  is 
not  a  tangible  product  or  physical  system  whereas  hardware  is  and  you  can 
see  and  measure  the  developmental  process  better  than  you  can  for  software; 
2)  in  software  projects,  it  may  not  be  obvious  until  late  in  the  project  that  the  code 
is  meeting  or  not  meeting  the  requirements,  whereas  with  hardware  you  will  be 
able  to  tell  sooner  if  not  right  away;  and  3)  unlike  hardware  projects,  testing  and 
integrating  of  software  products  is  not  simple  and  can  yield  more  problems  late  in 
the  project. 

In  regard  to  CHSS  or  hardware  components  of  IT  programs,  they  are  most 

heavily  influenced  by  Moore’s  law,  which,  again,  predicts  the  doubling  of  capacity 
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per  unit  expenditure  every  18  months,  so  obsolescence  is  a  concern  if  hardware 
projects  take  years  to  develop  (NRC,  2010).  In  contrast  to  hardware  components 
of  IT  programs,  the  software  components  are  most  heavily  influenced  by  the  fast 
pace  of  technology  change  in  the  Internet  environment  and  the  difficulty  at  times 
to  define  requirements  (NRC,  2010).  In  both  types  of  IT  developments,  rapid 
change  is  a  fundamental  factor  that  must  be  addressed,  and  iterative, 
incremental  development  (I ID)  strategies  are  indeed  appropriate  ways  to  address 
this  rapid  change,  especially  when  done  quickly  (NRC,  2010).  However,  the 
nature  of  the  capability  increments  should  differ  for  hardware  and  software 
components  because  of  the  different  issues  that  drive  them.  Thus,  the  SDCI  and 
CHSS  frameworks  were  designed  to  capture  these  differences  in  their 
developmental  approaches.  Following  are  descriptions  of  the  proposed  program 
phases  and  decision  milestones  for  both  the  SDCI  and  CHSS  programs. 

Software  Development  and  Commercial  off-the-shelf  (COTS)  Integration  (SDCI) 
programs  consist  of  the  following  decisions  and  phases  as  shown  in  Figure  10: 

•  Material  Development  Decision.  The  purpose  of  the  Material 
Development  Decision  (MDD)  is  to  validate  the  need  for  material 
development  to  address  the  requirement  for  a  new  or  improved 
mission  capability  as  a  result  of  a  projected  deficiency  or 
obsolescence  in  existing  systems  that  cannot  be  addressed 
appropriately  through  continued  evolution  of  those  systems;  a 
technological  opportunity;  or  an  opportunity  to  reduce  operating 
cost.  An  additional  purpose  is  to  gain  approval  of  a  draft  top-level 
(“big-R”)  capability  description  and  draft  concept  of  operations 
(CONOPS)  for  the  capability. 

•  Business  Case  Development.  This  phase  enables  leadership  to 
make  an  informed,  rational  initial  decision  to  invest  in  a  program.  It 
should  further  evolve  the  draft  capability  description  and  draft 
CONOPS  and  develop  alternative  approaches  or  system  concepts 
for  the  proposed  program.  It  should  formalize  the  approach  to 
quantify  costs  that  will  be  incurred  in  the  program  and  benefits 
expected  to  be  achieved  by  the  program,  and  conduct  an  analysis 
of  the  trade-offs  among  the  alternatives  to  assess  the  anticipated 
costs  and  benefits  of  each  in  order  to  recommend  a  preferred 
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approach  or  system  concept.  It  should  also  identify  major  risk 
factors  that  could  jeopardize  success  and  propose  mitigation 
strategies  for  each  major  risk  factor.  In  so  doing,  it  should  develop  a 
proposed  schedule  and  budget  for  the  capability  increments  from 
the  initial  capability  increment  through  to  the  final  capability 
increment  and  anticipated  lifecycle  costs,  and  propose  an  allocation 
of  the  top-level  requirements  identified  in  the  draft  capability 
description  to  the  capability  increments. 

•  Milestone  A:  Planning,  Analysis,  and  Concept  Demonstration 

Decision  Phase.  The  purpose  of  this  decision  is  to  validate  the 
business  case  and  analysis  of  alternatives,  and  to  authorize  entry 
into  the  initial  Planning,  Analysis,  and  Concept  Demonstration 
Phase. 

•  Increment  1  Planning,  Analysis,  and  Concept  Demonstration 

Phase.  The  purpose  of  this  phase  is  to  provide  further  validation  of 
the  recommended  alternative  approach  and  its  projected  costs  and 
benefits  prior  to  formal  initiation  of  the  program.  Also,  this  phase 
can  use  prototyping  to  demonstrate  key  features  of  the  proposed 
solution. 

•  Increment  2  Planning,  Analysis,  and  Concept  Demonstration 

Phase.  The  purpose  of  this  phase  is  to  allow  for  subsequent 
planning  and  analysis  phases  after  the  initial  one  leading  to  the 
initial  Milestone  B,  Program  Initiation  Decision. 

•  Milestone  B:  Program  or  Capability  Increment  Initiation  Decision. 
The  purpose  of  this  decision  is  to  validate  the  overall  refined 
capability  description  and  how  big-R  requirements  are  allocated 
across  all  subsequent  increments,  and  the  time-phased  scope  of 
deploying  capability  across  the  increments.  It  must  also  validate  the 
proposed  small-r  refined  requirements  allocated  to  the  next 
increment,  together  with  the  plan  for  how  the  increment  will  be 
executed. 

•  System  Development  and  Demonstration  (SDD)  Phase.  The 
purpose  of  this  phase  is  to  develop  the  next  increment  of  capability 
through  a  learning  and  communicating  cycle  of  time-boxed 
iterations  informed  by  the  end-user’s  perspective  and  integrated 
testing  and  evaluation  as  key  components  of  the  learning  and 
communications  process  throughout  the  iterations. 
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•  Milestone  C:  Capability  Increment  Deployment  Decision.  The 
purpose  of  this  decision  is  to  assess  the  risk  versus  benefit  of 
deploying  the  capability  developed  during  the  SDD  phase  to  the 
subset  of  end  users  within  the  intended  deployment  scope.  This  is 
a  marked  departure  from  the  current  approach  of  assessing 
whether  a  fixed  set  of  requirements  including  key  performance 
parameters  (KPPs)  has  been  achieved  with  cost  and  schedule 
floating  to  whatever  level  is  necessary  to  achieve  that  objective.  In 
this  approach,  the  increment  is  time-boxed  and  executed  with  the 
cost  and  schedule  constrained  to  the  baseline  set  at  the  previous 
Milestone  B  decision  and  the  degree  of  success  in  meeting  the  big- 
R  requirements  set  for  the  increment. 

•  Deployment  Phase.  The  purpose  of  this  phase  is  to  deploy  the 
developed  capability  to  the  intended  subset  of  end  users.  If  the 
capability  developed  during  the  SDD  Phase  and  its  deployment 
approach  is  straightforward,  the  Deployment  Phase  can  be  a  very 
simple  and  straightforward  activity.  If,  however,  the  capability  is 
complex,  and  especially  if  there  are  interdependencies  with  other 
programs,  complex  installation  procedures  not  suitable  for  “point- 
and-click”  installation  by  the  end  user,  and/or  unique  training 
requirements,  significant  planning  and  effort  may  be  required  to 
deploy  the  capability. 

•  Operations  and  Sustainment  Phase.  The  purpose  of  this  phase  is 
to  support  all  previously  deployed  versions  of  a  capability  still  in 
operational  use.  This  support  includes  activities  such  as  operating 
an  end-user  help  desk  and  responding  to  problems  encountered  in 
operational  use  of  the  capability,  including  the  development  and 
distribution  of  patches  and  maintaining  a  configuration  status 
accounting  baseline  for  all  installations  of  the  capability  (NRC, 
2010). 
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Figure  10.  SDCI  Framework  (From  NRC,  2010) 


As  depicted  in  Figure  1 1 ,  COTS  hardware,  software,  and  services  (CHSS) 
programs  consist  of  the  following  decisions  and  phases  which  are  the  same  or 
similar  to  SDCI  with  exceptions  where  indicated: 

•  Material  Development  Decision.  The  purpose  of  this  phase  for 
CFISS  is  the  same  as  for  SDCI  programs. 

•  Business  Case  Development.  The  purpose  of  this  phase  for  CHSS 
is  the  same  as  for  SDCI  programs,  though  with  much  greater 
emphasis  placed  on  aligning  the  business  strategy  and  investment 
strategy  with  the  technical  incremental  capability  strategy. 
Correspondingly,  there  should  be  much  less  emphasis  on  a 
concept  of  operations  (CONOPS)  for  purely  unmodified  COTS 
hardware,  software,  and  services. 

•  Milestone  A:  Planning,  Analysis,  and  Concept  Demonstration 
Decision  Phase.  These  decisions  for  CHSS  are  conceptually  similar 
to  those  for  SDCI  programs;  however,  the  difference  at  this 
decision  milestone  and  in  the  subsequent  program  phases  is  that 
concept  demonstration  should  be  undertaken  if  and  only  if  there  are 
clear  issues  or  questions  that  must  be  resolved  through 
demonstration  that  cannot  be  resolved  in  successive  capability 
increments.  This  will  frequently  not  be  the  case  for  the  use  of 
unmodified  COTS  products  or  services.  As  such,  concept 
demonstration  should  be  regarded  as  optional,  with  a  bias  to  not 
performing  it  for  most  programs.  The  principal  focus  should  be  on 
the  planning  and  analysis  activities. 
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•  Increment  1  Planning,  Analysis,  and  Concept  Demonstration 

Phase.  The  purpose  of  this  phase  for  CHSS  is  similar  to  SDCI 
programs  with  the  exception  of  the  change  in  emphasis  discussed 
in  Milestone  A  for  CHSS  programs.  Furthermore,  requirements  will 
typically  focus  on  capability,  capacity,  and  key  nonfunctional 
requirements  (e.g.,  operational  availability  and  environmental 
qualification  for  hardware). 

•  Increment  2  Planning,  Analysis,  and  Concept  Demonstration 

Phase.  The  purpose  of  this  phase  for  CHSS  is  the  same  as  that  for 
the  second  increment  in  SDCI  programs.  However,  for  subsequent 
planning  and  analysis  phases  after  the  initial  one  leading  to  the 
initial  Milestone  B,  Program  Initiation  Decision,  and  the  process  can 
be  substantially  abbreviated. 

•  Milestone  B:  Program  or  Capability  Increment  Initiation  Decision. 
The  purpose  of  this  decision  is  the  same  for  CHSS  as  those  for 
SDCI  programs. 

•  System  Development  and  Demonstration  (SDD)  Phase.  As  with 
SDCI  programs,  the  purpose  of  this  phase  for  CHSS  is  to  provide 
the  next  increment  of  capability.  Since  developmental  efforts  are 
not  involved,  the  nature  of  the  learning  and  communications  cycle 
and  the  role  of  the  end  user  and  other  stakeholders  change,  as 
does  integrated  testing  and  evaluation.  Also,  since  the  focus  is  on 
COTS  software  configuration,  hardware  integration,  or  hardware 
ruggedization  to  meet  environmental  qualification  requirements, 
and  not  on  software  development,  time-boxed  iterations  can  still 
play  a  role  but  are  not  as  critical  as  they  are  for  SDCI  programs. 

•  Milestone  C:  Capability  Increment  Deployment  Decision.  The 
purpose  of  this  decision  is  the  same  for  CHSS  as  SDCI  programs, 
with  one  addition:  validating  the  attainment  of  an  environmentally 
qualified  first  article  for  COTS  hardware  programs  targeted  at 
deployable  units.  As  with  SDCI  programs,  if  there  are  subsequent 
increments,  this  Milestone  C  decision  should  ideally  be  conducted 
coincident  with  the  Milestone  B  decision  for  the  subsequent 
increment  since  many  of  the  factors  affecting  the  deployment 
decision  can  also  materially  affect  the  composition  of  the  next 
increment. 
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•  Deployment  Phase.  The  purpose  of  this  phase  for  CHSS  is  the 
same  as  it  is  for  SDCI  programs. 

•  Operations  and  Sustainment  Phase.  The  purpose  of  this  phase  is 
the  same  for  CHSS  programs  as  it  is  for  SDCI  programs  (NRC, 
2010). 


Figure  1 1 .  CHSS  Framework  (From  NRC,  2010) 


Like  the  BCL  framework,  SDCI  and  CHSS  frameworks  use  phases  and 
decision  points  that  are  structured  within  an  IID  format  with  time-boxed  capability 
increments;  however,  SDCI  and  CHSS  increments  are  planned  in  4  to  8  week 
iterations  and  do  not  take  longer  than  12  to  18  months  to  deliver  meaningful 
capability  to  end  users  as  shown  in  Figures  10  and  11.  Essentially,  the  NRC 
provides  two  formats  for  IT  software  and  hardware  development  that  can  be 
completed  much  quicker  than  the  time  frame  indicated  for  the  BCL  process 
mainly  because  SDCI  and  CHSS  account  for  the  differences  in  developmental 
types.  Although  BCL  advertises  “flexible  and  tailorable  processes,”  it  does  not  go 
as  far  as  breaking  its  framework  down  for  the  different  types  of  developmental 
processes  for  IT. 

As  is  suggested  in  the  BCL  implementation  guidance,  tailoring  of  the  BCL 
framework  is  welcomed  (USD[AT&L],  2013).  With  that,  tailoring  to  account  for  the 
different  strategies  needed  to  address  the  different  needs  of  both  hardware  and 
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software  development  could  potentially  serve  to  expedite  the  BCL  process  which 
again,  can  take  as  long  as  5  years.  Essentially,  the  BCL  acquisition  process 
should  incorporate  the  processes  and  timelines  found  in  both  SDCI  and  CHSS 
process  models.  Doing  so  has  the  potentially  to  better  address  the  issues  for  the 
Navy’s  cyber  security  IT  needs  and  the  associated  speed  needed  to  acquire 
certain  technologies. 

In  regard  to  the  overall  change  recommendations  to  the  IT  acquisition 
process,  the  NRC’s  models  have  similar  attributes  similar  to  the  BCL  framework 
which  include  an  emphasis  on  shorter  cycle  times  to  deliver  the  best  IT  to  the 
warfighter;  streamlined  processes  for  requirements  definition,  budgeting, 
operational  testing,  and  oversight;  and  the  decomposition  of  larger  programs  into 
smaller  projects  or  increments  that  are  delivered  to  the  user  in  an  evolutionary 
manner  (NRC,  2010).  NRC’s  emphasis  on  shorter  cycles  include  time-boxed 
incremental  deliveries  of  usable  capabilities  and  time-boxed  iterations  within 
each  capability  increment  that  are  focused  on  nonfunctional  requirements  and  on 
an  architecture  that  is  suited  for  the  intended  operating  environment  (NRC, 
2010).  Furthermore,  NRC’s  streamlined  process  for  requirements  will  focus  on 
“big-R”  requirements  during  early  planning  and  performance  of  integrated  testing, 
and  evaluation  will  be  commensurate  with  risk  and  benefit.  The  NRC’s 
employment  of  I  ID  methods  incorporates  the  voice  of  the  end  users  as  well  as 
provides  an  acquisition  governance  process  that  empowers  end  users  in  the 
acquisition  oversight  decision  processes  (NRC,  2010).  The  decomposition  of 
larger  programs  and  decisions  driven  by  risk  and  benefit  will  provide  an 
incremental  build-out  of  the  architecture  in  scope  and  scale  sufficient  to  meet  the 
needs  of  the  functional  requirements  of  each  capability  increment  (NRC,  2010). 
Ultimately,  the  NRC’s  recommendation  offers  much  of  what  BCL  offers,  except 
the  timelines  provided  by  the  NRC  frameworks  implement  capabilities  much 
sooner. 
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2.  Four  Models  for  IT  Acquisition  for  Software  and  Hardware 
Development 

In  November  2009,  around  the  same  time  as  the  NRC’s  study,  Acquisition 
Solutions  Incorporated  (ASI)  conducted  its  own  assessment  of  the  IT  acquisition 
problem  within  the  DoD.  ASI  engaged  with  the  Deputy  Assistant  Secretary  of 
Defense  for  Command,  Control,  and  Communications,  Intelligence,  Surveillance, 
and  Reconnaissance  and  the  DoD  CIO  to  develop  an  alternative  model  for  IT 
acquisition  based  on  the  DSB  2009  report  (Gilligan  et  al.,  2009).  ASI  focused  on 
the  concepts  presented  in  the  DSB  report  in  order  to  develop  an  implementable 
acquisition  process  to  quickly  comply  with  the  new  congressional  mandate  and  to 
achieve  rapid  delivery  of  information  technology  solutions  that  meet  government 
users’  needs  (Gilligan  et  al.,  2009).  AIS  noted  the  following  factors  that  influence 
IT  acquisition  processes: 

•  The  technology  for  information  systems  exhibits  continuous  and 
very  rapid  evolution 

•  There  are  an  increasing  number  of  commercial  off-the-shelf 
(COTS)  components  available 

•  Users’  requirements  for  an  information  system  evolve  as  users  gain 
experience  with  early  capabilities 

•  Most  IT  systems  or  services  are  components  of  a  larger  “system  of 
systems.”  (Gilligan  et  al.,  2009) 

Furthermore,  ASI  cited  the  differences  in  the  types  of  IT  developmental  programs 
just  as  the  NRC  study  had  described.  ASI  also  emphasized  that  these 
differences  must  be  accommodated  in  the  acquisition  processes  government 
organizations  employ  in  order  for  the  IT  acquisition  process  to  be  effective 
(Gilligan  et  al.,  2009). 

Ultimately,  ASI  developed  a  set  of  guidelines  for  the  DoD  to  rapidly 
acquire  new  IT  systems.  These  guidelines  are  built  on  industry  best  practices, 
lessons  learned  from  both  industry  and  government,  and  are  tailored  specifically 
for  IT  acquisitions.  Also,  the  ASI  model  is  built  on  agile  development,  test,  and 

contracting  methods  to  achieve  rapid  delivery  of  products  (Gilligan  et  al.,  2009). 
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Accordingly,  ASI  established  six  principles  that  underpin  its  proposed  IT 
acquisition  models: 

•  Divide  requirements  for  larger  IT  solutions  into  smaller  projects. 

•  Use  acquisition  “process  templates”  that  recognize  the  differences 
among  types  of  IT  efforts. 

•  Use  CIO  and  acquisition  governance  authorities  as  well  as  end- 
user  approval  for  key  decisions  in  the  IT  acquisition  process. 

•  Employ  standard  IT  “platforms”  as  the  infrastructure  target  for  newly 
fielded  capabilities. 

•  Provision  and  employ  an  enterprise-wide  systems  engineering,  test, 
and  integration  capability. 

•  Use  portfolio  management-like  processes  for  project  initiation  and 
funds  allocation. 

ASI’s  Principle  1,  dividing  requirements,  involves  the  same  concept  used 
in  the  BCL  framework,  which  focuses  on  small,  incremental  projects  to  drive 
rapid  fielding  of  user  capabilities.  Also,  IT  requirements  are  defined  at  a  high 
level  at  the  start  of  a  project,  with  detailed  requirements  evolving  throughout  the 
project  (Gilligan  et  al.,  2009).  ASI’s  acquisition  model  uses  small  IT  projects  and 
interactively  evolves  the  results  of  these  smaller  efforts  into  the  larger  system 
capability  to  deliver  and  field  operational  capabilities  in  6-12  months  (Gilligan  et 
al.,  2009).  Additionally,  through  agile  developmental  methods,  the  IT  project’s 
developer,  the  knowledgeable  user,  and  the  tester  work  together  on  each 
increment  of  capability  which  results  in  rapid  delivery  of  useful  capability  and 
avoids  surprises  in  the  fielded  system  (Gilligan  et  al.,  2009).  Furthermore,  as  the 
increments  of  capability  are  fielded,  continuous  user  feedback  is  used  to  tailor 
the  requirements  and  priorities  for  successive  increments.  Essentially,  smaller 
projects  permit  less  overhead,  less  risk,  and  more  rapid  fielding,  which  helps  to 
ensure  that  the  program  is  meeting  user  needs.  Much  of  this  principle  mirrors  the 
BCL  concept  for  requirements  and  smaller  increments;  however,  the  timeline 
intends  to  deliver  capabilities  quicker  due  in  large  part  to  Principle  2. 
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Principle  2,  use  of  acquisition  “process  templates,”  is  similar  to  NRC’s 
recommendation  of  maintaining  different  process  models  based  on  the  type  of  IT 
being  acquired.  Once  again,  BCL  makes  reference  to  being  a  “flexible  and 
tailorable  process,”  but  it  does  not  go  as  far  as  explaining  this  flexibility  and  how 
its  framework  can  be  tailored.  ASI  noted  that  “as  IT  acquisition  projects  grow 
increasingly  complex,  the  risks,  acquisition  activities,  and  oversight  needs  of 
individual  programs  grow  more  diverse”  (Gilligan  et  al .,  2009).  Whether  it  is  for  a 
software  product  or  COTS  IT  component  acquisition  program,  there  are 
inherently  different  risks  and  requirements  to  be  met  for  each  type.  Therefore,  it 
is  necessary  that  the  acquisition  development  and  oversight  process  be  tailored 
to  meet  the  requirements  of  each  type  of  acquisition.  Thus,  utilizing  predefined 
acquisition  process  templates,  each  tailored  for  different  types  of  IT  projects, 
ensures  that  complex  IT  projects  stay  focused  on  those  activities  that  are 
important  for  that  particular  IT  acquisition  type  and  increases  the  speed  of  the 
acquisition  process  (Gilligan  et  al.,  2009).  For  a  new  IT  acquisition  model,  and 
similar  to  what  NRC  recommended,  ASI  proposed  four  process  templates  that 
leverage  best  practices  for  four  different  types  of  IT  acquisition  programs  and  the 
inherent  risks  with  each.  The  four  templates  identify  the  important  acquisition 
activities  needed  to  address  specific  risk  areas;  identify  the  key  decisions  points 
and  the  information  needed  to  support  the  decision  points;  and  define  specific 
project  planning  activities,  oversight  decision  points  tied  to  risks,  documentation 
needs,  and  decision  event  exit  criteria  (Gilligan  et  al.,  2009).  The  four  IT 
acquisition  process  templates  are  as  follows: 


•  Process  Template  1:  Application  Software  Development  and 
Integration — for  projects  involving  software  development  and 
software  integration 

•  Process  Template  2:  COTS  Hardware/Software — for  the  purchase 
of  non-modified  commercial  end  items 


93 


•  Process  Template  3:  Integrated  COTS  Capability — for  projects 
requiring  focused  systems  engineering  to  integrate  a  set  of 
commercially  provided  hardware  and/or  software  components 

•  Process  Template  4:  Commercially  Provided  IT  Services — for 
efforts  to  procure  IT  services.  (Gilligan  et  al 2009) 

Unlike  BCL,  acquisition  process  timelines  for  each  of  the  four  templates 
are  measured  in  months,  not  years,  which  makes  these  models  and  ASI’s 
concepts  even  more  appealing.  Process  Template  1  and  2  are  very  similar  to  the 
NRC’s  Software  Development  and  Commercial  off-the-shelf  Integration  (SDCI) 
model  and  the  COTS  hardware,  software,  and  services  (CHSS)  model  in  that 
they  provide  unique  processes  for  acquiring  these  two  different  types  of 
technologies.  Although  their  processes  and  the  names  of  their  phases  are 
different,  they  focus  on  the  same  areas  and  their  associated  timelines  are 
similarly  shorter  than  BCL.  However,  Process  Templates  3  and  4  provide  two 
different  aspects  of  IT  acquisitions.  Figures  12  and  13  show  the  top-level 
diagrams  of  both  Process  Templates  3  and  4,  respectively.  The  phases  and 
decision  points  for  these  four  process  models  are  consistent  with  or  similar  to  the 
phases  and  decision  points  found  in  the  BCL  framework  and  the  NRC  models. 
However,  the  most  significant  difference  involves  the  quicker  process  timelines 
found  in  the  four  models. 
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Process  Template  3:  Integrated  COTS  Capability 
(From  Gilligan,  Heitkamp,  &  McCoy,  2009) 
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Figure  13.  Process  Template  4:  Commercially  Provided  IT  Services 
(From  Gilligan,  Heitkamp,  &  McCoy,  2009) 
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Principle  3,  use  of  CIOs,  acquisition  governance  authorities,  and  end 
users  for  key  decisions,  is  fundamental  to  ASI’s  recommend  new  IT  acquisition 
process.  The  governance  process,  which  involves  the  CIO  community,  the 
acquisition  community,  and  the  user  community,  focuses  on  three  key 
governance  areas:  requirements  definition,  oversight  of  program  management 
processes,  and  management  of  the  use  of  information  technologies  (Gilligan  et 
al.,  2009).  Each  of  the  three  communities  brings  separate  but  essential 
authorities  and  accountability  to  the  acquisition  oversight  process,  “the 
acquisition  community  provides  program  management  and  contracting  expertise; 
the  CIO  community  provides  IT  architecture,  interoperability,  standards,  and 
information  assurance  expertise;  and  the  user  community  brings  expertise  and 
understanding  of  user  needs  and  priorities”  (Gilligan  et  al.,  2009).  Furthermore, 
qualified  representatives  from  each  community  are  given  the  authority  to  make 
timely  decisions  regarding  cost,  schedule,  and  performance  as  well  as  the 
responsibility  to  ensure  full  transparency  of  the  project  status  (Gilligan  et  al., 
2009).  Ultimately,  this  governance  structure  is  vital  to  the  proposed  model  and  an 
effective  IT  acquisition  system  because  “it  helps  to  ensure  that  the  right 
knowledge  and  authorities  are  available  to  make  the  decisions  necessary  to  keep 
an  IT  project  moving,  to  redirect  it  if  needed,  or  to  terminate  a  project  when 
appropriate”  (Gilligan  et  al.,  2009).  This  principle,  in  comparison  to  BCL,  is  very 
similar  to  the  governance  restructuring  found  in  BCL  but  the  use  of  CIOs  and  the 
importance  of  effective  management  is  given  more  emphasis. 

Principle  4,  use  of  standard  IT  platforms,  seeks  to  avoid  the  issue  of  DoD 
organizations  selecting  hardware  and  associated  software  that  use  a 
combination  of  commercially  available  technologies  that  are  assembled  and 
configured  by  different  systems  integrators  and  result  in  a  large  variety  of 
distinctly  different  hardware  and  software  platforms  that  must  be  properly 
configured,  tested,  and  managed  throughout  the  lifecycle  (Gilligan  et  al.,  2009). 
This  method  of  acquiring  IT  is  problematic  and  leads  to  delays  because  “each 
program  specifies,  purchases,  and  qualifies  its  own  unique  platform  for  security, 
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interoperability  and  stability;  is  expensive,  with  significant  duplication  and 
unnecessary  effort;  and  complicates  security  efforts”  (Gilligan  et  al. ,  2009).  Thus, 
ASI’s  new  approach  to  IT  acquisition  provides  direction  on  the  mission-unique  IT 
software  or  COTS  capabilities  by  using  standard  prequalified  IT  platforms  that 
implement  DoD  IT  standards  and  necessary  security,  and  can  be  provisioned 
quickly  (Gilligan  et  al.,  2009).  Lastly,  these  standard  platforms  can  be  made 
available  immediately,  which  will  enable  DoD  IT  projects  to  rapidly  take 
advantage  of  the  benefits  of  agile  development  methods  and  to  rapidly  field 
state-of-the-art  COTS  IT  products. 

Principle  5,  employment  of  an  enterprise-wide  test  and  integration 
capability,  deals  with  the  issue  of  government  acquisition  processes  that  often  do 
not  address  IT  integration  and  interoperability  objectives  until  an  IT  project  is 
already  developed  or  in  the  process  of  being  fielded.  Thus,  AIS  emphasizes  an 
organization-wide  systems  engineering  process  along  with  test  and  integration 
capabilities  (TIC)  to  provide  a  way  to  ensure  integration  and  interoperability  of 
separately  developed  projects  before  fielding  (Gilligan  et  al.,  2009).  Also,  TIC 
provides  a  means  to  reduce  project  cost  and  schedule  by  eliminating  the  need  for 
an  individual  IT  project  to  maintain  a  separate  and  distinct  test  and  evaluation 
facility  (Gilligan  et  al.,  2009).  Additionally,  TIC  would  be  used  to  1)  conduct 
prototype  evaluations  or  to  demonstrate  candidate  technologies  prior  to  a  build  or 
procurement  decision,  2)  test  newly  procured  capabilities  in  a  “system  of 
systems”  operational-like  environment  prior  to  fielding,  and  3)  ensure  compliance 
and  compatibility  within  established  IT  architectures  and  standards  and  other 
systems  that  exist  within  the  target  operational  environments  (Gilligan  et  al., 
2009).  Essentially,  TIC  addresses  many  of  the  testing  issues  that  were  described 
in  Chapter  II  by  providing  a  single  environment  for  developmental,  operational, 
and  security  testing  of  newly  developed  IT  capabilities. 

Principle  6,  use  of  a  portfolio  management-like  process  for  project 
initiation  and  funding  allocation,  is  one  of  the  most  important  principals  because  it 
addresses  part  of  the  funding  issues.  As  discussed  in  Chapter  II,  acquiring 
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funding  for  IT  projects,  even  high-priority  projects,  can  take  multiple  years.  Given 
the  fact  that  IT  advances  a  generation  every  18  months  and  many  mission-critical 
functions  depend  heavily  on  IT  solutions,  a  rapid  IT  acquisition  process  requires 
an  equally  rapid  funding  process  in  order  to  be  effective  (Gilligan  et  al.,  2009). 
Thus,  ASI’s  new  models  offer  a  portfolio  management-like  process  for  allocating 
funding  within  the  execution  year  and  permit  trade-offs  between  competing 
needs  that  will  lead  to  more  effective  use  of  IT  funds  (Gilligan  et  al.,  2009).  So 
rather  than  budgeting  and  managing  the  execution  of  funding  tied  to  one  specific 
project,  the  DoD  can  respond  to  advances  in  IT,  emerging  and  urgent  needs,  and 
the  progress  within  ongoing  IT  acquisition  projects  in  a  more  rapid  and  flexible 
manner  (Gilligan  et  al.,  2009).  This  flexibility  provides  the  means  to  be  able  to 
move  funding  around  within  the  portfolio  in  order  to  support  new  requirements 
discovered  during  IT  developmental  processes.  This  funding  process  would  be 
similar  to  the  DoD’s  use  of  working  capital  funds;  in  which  funding  for  IT  is 
allocated  annually  after  examination  of  priority  needs  and  project  progress 
(Gilligan  et  al.,  2009).  Ultimately,  this  portfolio  management-like  approach 
eliminates  the  need  to  have  full  funding  of  the  entire  IT  effort  at  project  initiation 
in  favor  of  incremental  funding  for  each  release  (Gilligan  et  al.,  2009). 
Unfortunately,  the  current  PPBE  process  does  not  facilitate  the  ASI’s  funding 
concept.  Furthermore,  this  proposed  change  to  acquisition  funding  methods  are 
contingent  upon  congressional  approval  or  action,  which  can  be  difficult. 

The  six  principles  and  four  models  proposed  by  ASI  extend  the  concepts 
identified  in  the  2009  DSB  report.  Also,  ASI  concepts  embody  the  best  practices 
of  industry  as  well  as  lessons  learned  from  successes  and  failures  within  DoD  IT 
acquisition.  Through  the  implementation  of  ASI  concepts,  the  DoD  can  achieve 
rapid  acquisition  of  useful  IT  while  providing  needed  and  effective  oversight.  In 
comparison  to  the  BCL  process,  ASI  provides  more  granularity  or  emphasis  in 
the  areas  of  funding  and  the  actual  acquisition  process  given  the  four  model  or 
frameworks  that  account  for  different  types  of  IT  acquisition.  Tailoring  the  BCL 
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process  to  account  for  the  different  process  models  and  timely  funding  methods, 
as  offered  in  the  ASI  models,  can  greatly  decrease  the  acquisition  timeline. 

3.  IT  360  Solution 

Recognizing  the  unacceptably  long  IT  acquisition  process  and  the  inherent 
problems  within  the  entire  system,  former  Under  Secretary  of  Defense  for 
Acquisition,  Technology,  and  Logistics  (USD[AT&L])  Jacques  S.  Gansler  and 
William  Lucyshyn,  proposed  an  entirely  new  IT  acquisition  model  in  2012.  They 
developed  a  new  IT  acquisition  process  entitled  “IT  360,”  which  is  specifically 
tailored  to  meet  the  unique  attributes  of  modern  Defense  business  systems 
(Gansler  &  Lucyshyn,  2012).  The  label  “IT  360”  is  a  conceptual  goal  to  mean  that 
this  process  intends  to  complete  one  developmental  cycle  in  approximately  360 
days  or  fewer  (Gansler  &  Lucyshyn,  2012).  Moreover,  IT360  contains  a  series  of 
initiatives  that  intends  to  enhance  the  speed  and  efficiency  with  which  DoD 
acquires  its  IT  systems.  These  initiatives  are  as  follows: 

•  Spiral  development 

•  Smaller,  quicker  to  deliver,  useful  sets  of  capabilities 

•  Rapid  delivery 

•  Greater  use  of  COTS  products 

•  Aggressive  use  of  prototypes  and  demonstrations 

•  Continuous  and  integrated  testing 

•  Decentralized  execution 

•  Inclusion  of  end  users 

•  Enhanced  competition  (Gansler  &  Lucyshyn,  2012) 

These  nine  initiatives  provide  a  means  for  the  IT  360  process  to  deliver  IT  in  a 
timely  manner.  The  IT  360  process  is  based  on  the  prevailing  commercial  model 
for  developing  software,  which  is  the  spiral  development  method  or  a  cyclical 
approach  to  incrementally  growing  a  system's  capabilities  while  decreasing  risk 
(Gansler  &  Lucyshyn,  2012).  Also,  spiral  development  facilitates  large  programs 
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being  broken  into  smaller,  agile  increments  that  are  responsive  to  innovation  and 
allow  for  the  rapid  development  of  new  capabilities. 

Rapid  development  and  time-to-delivery  are  key  objectives  for  every  IT 
program,  and  IT  360  employs  a  scheduling  concept  that  allows  the  traditional 
milestones  and  key  decision  points  to  be  established  early  in  the  process  and 
scheduled  in  much  shorter  periods  (Gansler  &  Lucyshyn,  2012).  For  example,  in 
IT  360,  the  time  allocated  to  complete  a  business  case  and  program 
implementation  plan  is  short  (approximately  30  days),  unlike  the  undefined 
timeline  for  this  phase  in  the  BCL  process.  In  an  effort  to  maintain  shorter 
timelines,  IT  360  promotes  greater  use  of  COTS  products  that  consist  of  proven 
capabilities  (i.e.,  pre-tested  and  pre-certified)  that  can  accelerate  deliveries  of 
capabilities  within  the  established  time  frame  (Gansler  &  Lucyshyn,  2012).  With 
that,  the  IT  360  process  encourages  the  use  of  prototypes  that  can  be  used  to 
expedite  source  selection,  reduce  technical  risk,  and  enable  the  selection  of 
developers  with  a  demonstrated  ability  to  implement  the  required  IT  system  for 
the  end  user. 

IT  360  has  several  other  important  factors  that  are  beneficial  to  the  IT 
acquisition  process.  For  instance,  IT  development  requires  a  continuous  cycle  of 
testing  in  order  to  detect  security  vulnerabilities  and  to  avoid  hyper-specified  and 
unnecessary  features  (Gansler  &  Lucyshyn,  2012).  Also,  this  continuous  testing 
permits  operational  experience  to  inform  future  requirements  that  will  ultimately 
ensure  that  IT  systems  are  optimally  suited  to  meet  the  needs  of  their  intended 
users  (Gansler  &  Lucyshyn,  2012).  Additionally,  IT  360  promotes  decentralized 
execution  and  frequent  product  reviews.  These  methods  alleviate  the  need  for 
burdensome  oversight  and  its’  associated  documentation  requirements  while  at 
the  same  time  including  users  and  other  stakeholders  throughout  the  process 
thus  allowing  program  personnel  and  developers  to  better  understand  user 
requirements  (Gansler  &  Lucyshyn,  2012).  One  other  important  factor  is 
competition  and  IT  360  enables  enhanced  competition  when  new  iterations  are 
launched.  Competition  is  an  important  component  to  effective  acquisition 
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because  it  promotes  efficiency  and  improved  market  performance  by  providing 
the  defense  industry  with  an  incentive  to  develop  better  products  quicker  and  at 
lower  costs  (Gansler&  Lucyshyn,  2012). 

IT  360  utilizes  both  an  evolutionary  (or  spiral)  and  an  incremental 
developmental  approach  to  IT  acquisition  (Gansler  &  Lucyshyn,  2012). 
Evolutionary  development  is  an  ongoing  process  of  spiral  development  of  system 
requirements,  which  are  based  on  feedback  loops  from  end  users.  Incremental 
development  is  essentially  a  process  for  implementing  evolutionary  acquisition 
yet  there  is  a  difference  between  evolutionary  and  incremental  processes  (Lorell, 
M.  A.,  Lowell,  J.  F.,  &  Younossi,  O.,  2006).  In  evolutionary  development,  the  end- 
state  requirements  are  not  known  in  advance.  This  is  an  important  conceptual 
distinction  between  evolutionary  and  incremental  developments  because  unlike 
spiral  or  evolutionary  development,  the  incremental  development  process 
assumes  that  the  end-state  requirements  are  known  at  the  beginning  of  the 
developmental  process.  Thus,  requirements  can  be  known  or  unknown,  and  IT 
360  is  designed  to  deal  with  both  scenarios.  In  using  both  an  evolutionary  and 
incremental  approach,  the  initial  IT  360  product  iteration  may  not  possess  all  of 
the  desired  capabilities  much  like  every  other  proposed  incremental  solution; 
however,  the  IT  360  process  adds  functionality  to  the  system’s  existing 
capabilities  at  a  standardized,  quick  pace  (Gansler  &  Lucyshyn,  2012). 

The  IT  360  framework  and  process  consists  of  seven  phases  that  interact 
in  a  spiral  fashion.  These  phases  consist  of  Program  Initiation;  Increment 
Requirement  Identification;  Initial  Increment  Level  Material  Development 
Strategy;  Architectural  Alignment  and  Development;  Development, 
Demonstration,  and  Oversight;  Increment  Capability  Delivery,  and  Operations 
and  Maintenance.  The  seven  phases  of  the  IT  360  process  and  their  objectives 
and  timelines  are  summarized  as  follows  and  are  depicted  in  Figure  14: 
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•  Program  Initiation  Phase.  The  initiation  phase  lays  the  foundation 
for  program  acquisition  in  four  distinct  ways.  First,  initial  market 
surveys  are  conducted  to  generate  potential  solutions  and  establish 
a  successful  acquisition  strategy.  Using  this  strategy,  the  high-level 
requirements  for  the  program  are  determined.  These  high-level 
requirements  (i.e.,  “big-R”  requirements)  specify  general  system 
capabilities.  Less  emphasis  is  placed  on  minor  requirements  (the 
over-specification  of  which  often  leads  to  cost  overruns  and 
delays);  rather,  minor  requirements  are  deferred  to  future 
increments.  Next,  both  the  high-level  requirements  and  the  market 
surveys  are  used  to  establish  the  overall  procurement  strategy, 
which  will  inform  future  phases  over  multiple  iterations.  Once  the 
strategy  is  established,  program-level  and  portfolio-level 
governance  are  then  created  and  initiated. 

•  Increment  Requirement  Identification  Phase.  During  this  phase,  all 
potential  solutions  are  considered,  including  COTS  and  other  open- 
source  solutions.  With  a  total  duration  of  approximately  30  days, 
the  secondary  goal  of  this  phase  is  to  ensure  that  capabilities  are 
assigned  to  appropriate  increments.  By  continuing  the  market 
surveys  begun  during  the  Program  Initiation  phase,  program 
personnel  work  to  ensure  that  the  initial  requirements  meet  as 
many  user  demands  as  possible,  without  front-loading  onto  early 
increments  the  more  difficult,  though  perhaps  nonessential, 
requirements.  This  is  an  important  distinction  over  the  traditional 
Defense  acquisition  system,  which  has  a  tendency  to  “waterfall” 
requirements,  leading  to  increased  rigidity  throughout  the  process. 
This  phase  concludes  with  a  material  development  decision  (MDD). 

•  Initial  Increment  Level  Material  Development  Strategy.  During  this 
phase,  a  procurement  strategy  that  is  both  product-specific  and 
increment-specific  is  devised.  While  much  of  this  strategy  was 
developed  during  the  previous  phase,  it  is  during  Phase  3  that 
program  personnel  delineate  a  highly  structured,  comprehensive 
business  case  (i.e.,  program  justification)  and  a  fully  developed 
acquisition  plan  and  develop  a  mechanism  that  ensures 
coordination  of  stakeholder  involvement.  With  an  approximate 
duration  of  30  days,  this  phase  finalizes  development  and  planning 
for  the  initial  increment.  The  Initial  Increment  Level  Material 
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Development  Strategy  phase  is  completed  upon  the  approval  of  a 
request  for  proposals  (RFP)  by  the  Program  Governance  Board 
(PGB). 

•  Architectural  Alignment  and  Development  Phase.  After  the  release 
of  an  RFP  to  private-sector  contractors,  the  Architectural  Alignment 
and  Development  phase  begins.  This  phase,  which  marks  the 
beginning  of  system  development,  has  a  duration  of  approximately 
120  days.  Once  the  architecture  is  determined,  a  risk  assessment 
is  conducted  via  prototyping  and  other  methods.  Once  it  is 
determined  that  the  architecture  carries  sufficiently  low  risk,  Phase 
4  concludes,  which  prompts  the  issuance  of  the  capabilities 
development  document  (ODD)  detailing  why  the  system  is  needed; 
how  it  will  be  used;  where  the  system  will  be  located;  who  will  need 
it;  when  it  will  be  available;  what  the  system  is  intended  to  do;  how 
the  system  will  be  supported;  and  how  much  it  will  cost.  Contracts 
are  written  to  reflect  the  information  contained  in  the  ODD. 

•  Development,  Demonstration,  and  Oversight  Phase.  The  issuance 
of  a  ODD  marks  the  beginning  of  the  Development,  Demonstration, 
and  Oversight  phase,  as  well  as  the  contract  award.  With  an 
approximate  duration  of  180  days,  it  the  longest  phase  of  the  IT  360 
process  but  also  the  most  crucial.  At  this  milestone,  the  decision 
authority  approves  the  acquisition  strategy;  enterprise  contracting 
and  buying  strategy;  increment  level  detailed  requirements;  and 
market  and  spend  analysis,  acquisition  program  baseline,  program 
implementation  plan,  test  plan,  and  documentation.  During  this 
phase,  the  program  manager  will  manage  the  development  and 
demonstration  of  the  proposed  IT  solution  for  a  release  of 
capabilities  within  specified  cost,  schedule,  and  performance 
parameters.  Additionally,  during  this  phase,  multiple  iterations  of 
the  system  may  be  developed  and  tested  (T&E  is  integrated  into 
each  iteration).  Upon  the  release  of  each  iteration,  stakeholder 
input,  oversight,  and,  if  appropriate,  corrective  actions  are 
combined  to  guide  development  of  the  next  iteration.  When 
successful,  the  program  manager  can  rapidly  deploy  the  capability 
or  continue  to  demonstrate  the  capability  in  a  live  operational 
environment,  depending  on  the  nature  of  the  program. 

•  Increment  Capability  Delivery  Phase.  Assuming  that  the  system 
fulfills  the  strategic,  programmatic,  and  incremental  requirements, 
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the  PGB  will  authorize  its  entry  into  the  Increment  Capability 
Delivery  phase.  This  phase  has  two  main  functions:  full  fielding  and 
the  transition  to  long-term  operations  and  maintenance  (O&M).  The 
second  function  is  the  transition  of  the  product  to  long-term  O&M. 
This  entails  the  creation  or  augmentation  of  a  support  structure 
specifically  tailored  to  the  capabilities  of  the  newest  product 
iteration. 


Operations  and  Maintenance  Phase.  The  Operations  and 
Maintenance  phase  oversees  the  creation  or  augmentation  of  a 
support  structure  specifically  tailored  to  the  capabilities  of  the 
released  product.  This  entails  complementary  documentation  and 
ongoing  training  in  support  of  the  recent  release,  refreshment  of 
software,  bug  fixes,  and  administrative  support.  Entrance  into  this 
phase  depends  heavily  on  the  user’s  satisfaction  with  the  solution 
and  willingness  to  use  the  IT  capability  in  the  operational 
environment.  The  support  plan  is  executed  to  meet  the  operational 
needs  of  the  IT  system  in  the  most  cost-effective  manner.  This  plan 
will  identify  strategies  to  respond  to  discrepancies,  failure  reports, 
and  hardware  and  software  updates  and  upgrades.  (Gansler  & 
Lucyshyn,  2012). 
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Figure  14.  The  IT  360  Process  (From  Gansler  &  Lucyshyn,  2012). 
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Gansler  and  Lucyshyn’s  IT  360  framework  has  four  primary  objectives: 

1)  provide  practical  capabilities  to  the  DoD  enterprise  quickly  and  efficiently, 

2)  incorporate  commercial  management  practices  to  reduce  overall  risk,  3)  grant 
maximum  flexibility  to  the  Milestone  Decision  Authority  (MDA)  to  reduce  the 
reporting  and  administrative  burden,  and  4)  respond  effectively  to  the  end-users’ 
needs.  The  IT  360  process  removes  many  of  the  obstacles  that  have  hindered  IT 
acquisition;  however,  it  will  not  remove  all  of  the  obstacles.  Thus,  Gansler  and 
Lucyshyn  identified  several  initiatives  or  actions  needing  to  take  place  in  order  to 
support  the  IT  360  process  and  mitigate  process  shortfalls.  These  initiatives 
include  document  streamlining,  flexible  contracting  mechanisms,  and  the 
implementation  of  forward-looking,  technology-neutral  standards. 

There  are  many  similarities  between  IT  360  and  BCL  but  there  are  also 
clear  distinctions.  For  the  acquisition  of  Defense  business  systems,  each 
framework  features  smaller  increments,  continuous  testing,  and  iterative 
prototyping  to  improve  performance  and  increase  efficiency  in  order  to  deliver 
capabilities.  The  differences  between  the  two  begin  with  their  developmental 
process.  The  IT  360  developmental  process  is  fundamentally  different  from  the 
BCL  process  in  its  phases  and  approach  within  each  phase.  IT  360  appears  less 
cumbersome  and  more  efficient.  Also,  IT  360  employs  a  far  more  superior 
timeline  in  producing  capabilities  as  it  intends  to  deliver  capabilities  within  a  year 
while  BCL  is  still  within  its  Investment  Management  or  its  Prototyping  phase 
within  its  first  year. 
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V.  CONCLUSION 


A.  PERSISTING  ISSUES  FOR  BCL  OR  ANY  NEW  IT  ACQUISITION 

SOLUTION 

Gansler  and  Lucyshyn  identified  a  number  of  challenges  and  barriers  that 
must  be  overcome  in  order  for  IT  360  to  be  successful;  however,  these 
challenges  and  barriers  are  not  exclusive  to  the  IT  360  proposal  but  apply  to 
every  other  solution  proposed  including  the  BCL  process.  Some  of  the  most 
persistent  challenges  to  timely  IT  acquisition  include  achieving  commercial  best 
practices  (e.g.,  contracting  practices),  spending  cuts,  funding  methods,  workforce 
issues,  and  the  inherent  difficulty  of  implementing  change  (e.g.,  a  new  acquisition 
process).  The  barriers  to  timely  IT  acquisition  consist  of  laws  and  regulations  that 
were  written  by  Congress  to  improve  oversight  within  the  Defense  Acquisition 
System  but  have  inadvertently  created  barriers.  Furthermore,  these  barriers 
involve  issues  within  research  and  development  reporting,  MAIS  reporting 
thresholds,  designated  DoD  authorities,  and  specified  appropriations. 

1.  Barriers 

Research  and  Development  (R&D)  reporting  continues  to  require  that  all 
R&D  funds  used  for  programs  be  submitted  to  Congress  at  the  beginning  of  the 
program  to  ensure  that  funding  is  accounted  for  and  that  oversight  is  adequate. 
This  process  is  problematic  given  the  evolutionary  nature  of  BCL,  IT  360,  and 
other  frameworks  that  use  incremental  development.  Additionally,  acquisition 
funding  remains  inflexible  and  cannot  be  applied  throughout  an  IT  acquisition 
portfolio. 

MAIS  reporting  thresholds  create  barriers  because  unlike  non-MAIS 
programs,  these  programs  are  subject  to  more  rigid  reporting  standards  (Gansler 
&  Lucyshyn,  2012).  Since  Defense  business  systems  often  meet  MAIS  cost 
thresholds,  Defense  business  systems  acquired  using  IT  360  and  similar 
approaches  may  be  subject  to  the  MAIS  reporting  process,  which  can  hinder 
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acquisition  because  it  does  not  facilitate  incremental  development  (Gansler  & 
Lucyshyn,  2012).  Portfolio-level  reporting  for  MAIS  Defense  business  systems 
should  be  implemented  to  resolve  this  issue. 

The  designation  of  authority  for  all  DoD  acquisitions  remains  ambiguous 
even  for  the  new  BCL  process.  For  instance,  USD(AT&L)  is  responsible  for  the 
guidance  and  policy  of  the  new  BCL  IT  acquisition  process;  however,  the  DCMO 
is  responsible  for  its  implementation  along  with  the  DoD  CIO  who  is  responsible 
for  agile,  secure,  efficient,  and  effective  DoD  IT  (Porter,  2012).  Another  example 
is  the  authority  of  investment  review  boards  (IRBs).  The  IRB’s  ability  to  analyze 
the  strength  of  an  IT  investments  remains  separate  from  the  authority  of  the 
CIO’s  responsibility  to  ensure  product  integration,  which  results  in  more 
ambiguity  in  oversight  and  decision-making  authority  (Gansler  &  Lucyshyn, 
2012).  Essentially,  oversight  and  responsibility  may  be  applied  inconsistently  and 
can  be  detrimental  to  an  IT  acquisition  program’s  success. 

Lastly,  appropriation  methods  for  IT  remain  problematic.  Under  any  of  the 
proposed  incremental  developmental  approaches,  requirements  may  be  added 
or  changed  after  the  budget  is  completed;  however,  this  flexibility  is  jeopardized 
because  of  the  appropriation  methods  and  its  requirement  that  all  funds 
appropriated  by  Congress  must  be  used  only  for  the  programs  and  purposes  for 
which  the  appropriation  was  made  (Gansler  &  Lucyshyn,  2012).  This 
appropriations  issue  is  one  part  of  the  overall  funding  issue  that  remains  to  be  a 
challenge  and  will  be  discussed  further  in  the  next  section. 

2.  Challenges  that  Remain  for  Any  IT  Acquisition  Solution 

a.  Achieving  Commercial  Best  Practices 

The  commercial  industry  has  enjoyed  great  success  in  employing 
an  agile  IT  acquisition  approach.  To  deliver  software  and  hardware  capability 
more  rapidly,  the  commercial  industry  has  embraced  the  iterative,  incremental 
development  (IID)  approach.  The  IID  approach  addresses  two  important  issues 
for  IT  systems:  the  need  for  user  interaction  in  setting  requirements  and  the 
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complexity  of  development  (NRC,  2010).  Key  attributes  of  the  commercial  IID 
approach  include  the  prominence  of  the  end-user’s  involvement,  a  focus  on 
requirements  during  early  planning,  the  close  integration  of  developmental  and 
operational  testing  and  evaluation  into  the  development  cycle,  and  the  breaking 
down  of  projects  into  increments  (NRC,  2010).  Additionally,  commercial  IT 
market  leaders  manage  IT  demands  by  instituting  standardization  and  discipline 
at  the  heart  of  their  respective  IT  enterprises  while  enabling  agile,  customer-led 
innovation  at  the  edge  of  these  enterprises  (NRC,  2010).  In  fact,  most  large  IT 
providers  have  developed  highly  reliable,  available,  and  scalable  computing 
environments  as  pillars  of  their  products  and  services  provided. 

Many  successful  commercial  IT  providers  have  organized 
development  around  two  key  principles:  portfolio  management  and  development 
by  small  teams  (NRC,  2010).  Portfolio  management  is  an  effective  method  when 
limited  resources  impact  IT  acquisition  because  “limited  resources  are 
strategically  allocated  to  a  subset  of  possible  projects  where  project  risk,  overall 
objectives,  costs,  benefits,  and  project  interdependencies  are  all  weighed,  and  a 
corporate-level  decision  is  rendered  on  strategic  investments”  (NRC,  2010). 
Lastly,  the  greatest  benefit  of  commercial  industry  practices  is  their  timely 
development  of  IT  products  and  services.  Commercial  technology  evolution 
cycles  for  communications,  computers,  and  software  average  18  months 
(Gilligan  et  al .,  2009).  For  example,  successful  commercial  practices  are  seen 
and  utilized  in  companies  such  as  Apple  and  Microsoft.  These  two  industry 
leaders  are  able  to  produce  products,  both  hardware  and  software,  in  an  efficient 
and  timely  manner  while  meeting  consumer  requirements  and  demands.  Their 
use  of  best  commercial  practices  continues  to  set  them  up  for  success. 

The  DoD  desires  an  acquisition  process  that  is  modeled  after 
“successful  commercial  practices  for  the  rapid  acquisition  and  continuous 
upgrade  and  improvement  of  IT  capabilities”  (DSB,  2009).  Modeling  successful 
commercial  practices  means  that  the  DoD  would  be  able  to  deliver  meaningful 
capabilities  that  meet  requirements  in  a  more  agile  manner  over  a  much  shorter 

109 


period  of  time.  Successful  commercial  practices  are  typically  at  the  leading  edge 
of  innovation  and  technological  advancements  where  DoD  needs  to  take 
advantage;  however,  doing  so  remains  a  challenge  for  the  DoD.  For  instance, 
even  where  the  DoD  attempts  to  adopt  commercial  practices,  government 
contracting  differs  significantly  from  commercial  best  practices  due  to  regulatory 
and  legislative  factors  (e.g.,  fiscal  constraints,  transparency  requirements,  and 
the  requirements  for  audit  and  oversight)  (Gansler  &  Lucyshyn,  2012).  As  a 
result,  contracting  practices  pose  a  challenge  due  to  the  inflexibility  found  in 
government  contract  procedures. 

In  order  for  the  DoD’s  business  systems  to  remain  current  as  the 
pace  of  change  in  IT  accelerates,  greater  contract  flexibility  is  required. 
According  to  Gansler  and  Lucyshyn  (2012),  contracts  must  be  structured  to 
reflect  evolving  requirements  and  incremental  developments  and  decisions 
(Gansler  &  Lucyshyn,  2012).  For  instance,  program  managers  need  to  possess 
the  level  of  authority  to  be  flexible  in  order  to  be  able  to  defer  requirements  to  the 
next  increment  when  necessary.  However,  DoD  contracting  practices  generally 
do  not  provide  program  mangers  with  this  level  of  flexibility  (Gansler  &  Lucyshyn, 
2012). 


b.  Acquisition  Funding  for  Incremental  Development 

A  remaining  challenge  to  achieving  timely  IT  acquisition  that  limits 
the  effectiveness  of  the  BCL,  IT  360,  and  other  proposed  incremental 
approaches,  are  IT  acquisition  funding  procedures.  As  discussed  in  Chapter  II, 
the  source  of  the  funding  problem  in  IT  acquisition  is  the  DoD’s  Planning, 
Programming,  Budgeting,  and  Execution  (PPBE)  system.  The  PPBE  system 
operates  on  a  timeline  that  is  inconsistent  with  the  fast-paced  IT  commercial 
marketplace  and  offers  no  flexibility  to  be  able  to  respond  to  the  rapid  changes  in 
IT.  For  example,  after  Congress  appropriates  funding  based  on  programs  and 
appropriations,  this  allocation  scheme  becomes  problematic  when  a  program  is 
allocated  enough  funding  for  development  but  later  requires  funding  to  support 
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additional  testing.  Under  the  current  appropriations  system,  reallocation  of  funds 
among  phases  is  impermissible  and  to  exacerbate  matters  further,  the  budget 
component  of  the  PPBE  process  requires  a  3-year  lead  time  (Gansler  & 
Lucyshyn,  2012).  Furthermore,  IT  programs  are  individually  funded  by  separate 
appropriations  with  unique  rules  and  definitions  for  each.  This  PPBE  funding 
method  continues  to  be  an  unresolved  issue  and  will  certainly  impact  any  new  IT 
acquisition  process,  including  BCL.  According  to  the  DoD’s  report  to  Congress  in 
2010  regarding  a  new  approach  for  delivering  IT  capabilities  within  the  DoD,  the 
DoD  stated: 

In  the  new  IT  acquisition  approach  [BCL],  a  business  case 
evaluation  of  alternatives,  supported  by  appropriate  BPR,  will  be 
conducted,  and  the  materiel  solution  will  be  selected  just  prior  to 
project  initiation,  ensuring  that  the  latest  technologies  are 
considered.  However,  if  the  Department  uses  traditional  Planning, 
Programming,  Budgeting  and  Execution  System  (PPBE)  processes 
to  plan,  program,  and  budget  based  on  the  approved  business 
case,  there  will  be  a  risk  of  incurring  up  to  a  two-year  delayed 
project  start.  (DoD,  2010) 

With  this  being  the  case,  the  incremental  processes  of  BCL,  or  of  any  other 
solution,  is  vulnerable  to  the  same  funding  issues  that  have  negatively  impacted 
IT  systems  acquired  using  the  traditional  acquisition  system.  The  prevailing 
guidance  on  the  DoD’s  newest  approach,  found  in  the  DTM,  does  not  address 
funding  methods  or  this  particular  funding  issue. 

The  DoD  has  considered  a  few  alternatives  in  the  past  in 
addressing  this  funding  issue.  These  alternative  approaches  to  addressing  the 
funding  issue  include  obtaining  a  single  appropriation  type  for  IT  projects, 
establishing  an  IT  revolving  fund,  and  redefining  a  funding  element  that  more 
accurately  reflects  the  nature  of  IT  capability  investment  (DoD,  2010).  The 
alternative  of  obtaining  a  single  appropriation  type  for  IT  projects  would  provide 
beneficial  funding  flexibility  for  development,  procurement,  and  operations  and 
maintenance  and  will  also  permit  the  funding  of  a  range  of  potential  IT  materiel 
solutions  (DoD,  2010).  The  alternative  to  establish  an  IT  revolving  fund  to  permit 
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incremental  funding  of  alternatives  to  support  the  entire  IT  investment  would  also 
be  beneficial;  however,  with  this  alternative,  projects  will  need  to  be  authorized 
through  a  series  of  internal  controls  (e.g.,  congressional  notification)  based  on 
defined  dollar  thresholds  of  the  planned  procurement.  Lastly,  the  alternative  of 
redefining  a  funding  element  would  provide  the  DoD  with  the  necessary  flexibility 
to  realign  funding  to  proposed  projects  with  sound  business  cases  (DoD,  2010). 
Of  these  considerations,  obtaining  a  single  appropriation  type  for  IT  and 
redefining  a  funding  element  would  both  be  viable  options;  however,  establishing 
an  IT  revolving  fund  with  congressional  control  over  the  types  of  projects  that  can 
be  funded  makes  this  alternative  less  attractive  and  more  cumbersome  and 
subject  to  delays  due  to  the  congressional  bureaucracy.  Regardless  of  the 
funding  alternative  selected,  the  DoD  has  to  request  legislative  action  to  change 
the  current  PPBE  system  in  order  to  better  facilitate  BCL  and  rapid  IT  acquisition. 

c.  Defense  Spending  Cuts  and  the  Impact  on  Agile  IT 
Acquisition 

Funding  issues  cannot  be  discussed  without  addressing  the  current 
Defense  spending  cuts  as  it  relates  to  IT  acquisition.  Chief  among  the  conceptual 
IT  acquisition  changes  provided  by  all  the  proposed  solutions  and  frameworks  is 
the  emphasis  of  an  agile  or  incremental  developmental  process.  The  agile 
developmental  process  demands  quick  development  of  smaller  pieces  of  a 
potentially  larger  program  or  large  deliverables  broken  into  constituent  units  that 
are  then  prototyped  and  tested  far  more  quickly  than  if  the  entire  program  had 
been  built  before  testing  occurred  (Porche  et  al.,  2012).  Implications  of  an  agile 
approach  and  why  it  remains  difficult  to  achieve  relates  to  the  current  fiscal 
environment. 

Defense  budget  cuts  will  continue  to  impact  the  DoD’s  plan  to 
execute  effective  IT  acquisition.  In  July  2013,  Defense  Secretary  Chuck  Hagel 
warned  the  Senate  Armed  Services  Committee  that  automatic  budget  cuts  have 
already  negatively  impacted  DoD  "severely  damaging  military  readiness” 
(Philpott,  2013).  Hagel  went  on  to  say  that  the  Department  "would  seek  to 
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minimize  cuts  in  the  day-to-day  operating  costs  most  closely  related  to  training 
and  readiness,”  but  without  relief,  Defense  spending  will  take  another  $52  billion 
hit  in  fiscal  year  2014.  Readiness  is  most  associated  with  planning  for  and 
acquiring  assets  for  mission  needs,  which  directly  relates  to  all  of  the  DoD’s 
acquisition  activities  including  personnel.  Defense  budgets  cuts  are  especially 
concerning  for  the  agile  acquisition  concept  and  new  process  implementation 
due  to  what  would  be  required  in  regards  to  funding  to  make  it  all  possible.  If 
agile  IT  is  desired,  then  additional  people,  materials,  and  money  are  going  to  be 
required  to  make  numerous  IT  acquisition  actions  happen  along  program 
lifecycles,  which  includes  development,  engineering,  testing,  security,  and 
accreditation  among  other  things.  Furthermore,  in  this  day  and  age  of 
sequestration  and  shrinking  Defense  budgets,  it  is  getting  increasingly  more 
difficult  for  the  DoD  to  provide  agile  IT  acquisition  when  resources  are  not 
available.  Lastly,  the  DoD’s  current  motto  is  “doing  more  without  more”  as  been 
expressed  by  Frank  Kendall  in  the  DoD’s  Better  Buying  Power  Memorandum 
(OUSD[AT&L],  2012).  Essentially,  this  motto  means  doing  more  with  less,  but  it 
appears  infeasible  to  cut  cost  and  attempt  to  improve  a  process  that  requires 
increasingly  more  funding.  Due  to  the  DoD’s  enormous  IT  appetite,  acquisition 
executives  and  senior  leaders  in  the  Department  need  to  reconcile  the  dilemma 
between  cutting  cost  and  acquiring  IT  as  rapidly  as  possible. 

There  is  an  axiom  in  government  acquisition  regarding  cost, 
schedule,  and  performance  whereby  an  end  user  only  gets  to  choose  two  of 
these  three  factors,  for  example  cost  and  schedule,  where  the  cost  is  implied  to 
be  lower  and  the  schedule  is  implied  to  be  more  timely.  However,  choosing  both 
cost  and  schedule  will  put  performance  at  risk,  for  if  an  end  user  gets  the  product 
cheap  and  fast,  it  may  not  be  good,  according  to  the  axiom.  Whether  this  axiom 
is  true  or  not,  the  point  here  is  that  the  DoD  desires  agile  IT,  and  to  acquire  IT 
systems  fast,  it  will  definitely  cost  more  money  and  the  required  performance 
may  or  may  not  be  available  depending  on  the  stage  of  the  incremental 
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development  approach.  Thus,  funding  remains  to  be  a  significant  issue  for  BCL 
and  any  other  framework  to  be  effective  and  the  DoD  has  to  resolve  this  matter. 

d.  The  Acquisition  Workforce  and  Acquisition  Management 

One  of  the  most  important  aspects  to  achieving  effective  IT 
acquisition  involves  the  quality  and  quantity  of  the  acquisition  workforce.  Quality 
equates  to  the  experience,  knowledge,  and  management  ability  of  the  workforce. 
In  regard  to  quantity,  the  acquisition  workforce  has  been  significantly  reduced 
over  the  past  20  years,  which  has  resulted  in  a  reduction  in  the  DoD’s  internal 
technical  competencies  (Gansler  &  Lucyshyn,  2012).  Furthermore,  over  60 
percent  of  the  government  IT  acquisition  workforce  is  older  than  45  years  of  age, 
and  many  workers  lack  the  specialized  IT  skills  found  in  the  younger  generation 
(Gansler  &  Lucyshyn,  2012).  Ultimately,  the  workforce  and  management  issues 
addressed  in  Chapter  II  have  not  been  resolved  in  their  entirety  within  any  of  the 
proposed  solutions  including  the  BCL  process,  for  no  plan  specifically  addresses 
workforce  improvements  and  its  alignment  with  a  new  acquisition  process. 

The  2009  DSB  task  force  believed  that  improvements  in  four 
specific  areas  would  ultimately  improve  the  acquisition  of  IT  in  DoD:  acquisition 
policies  and  process,  roles  and  responsibilities  of  the  CIO,  milestone  decision 
authority  roles  and  responsibilities,  and  acquisition  leadership  and  expertise 
(DSB,  2009).  Of  these  four  areas,  the  acquisition  leadership  within  the  workforce 
is  key  and  more  must  be  done  to  improve  this  critical  element  of  IT  acquisition. 
Regardless  of  any  new  acquisition  concept  or  theory  implemented,  it  is  the 
people  who  are  the  drivers  of  success  and  the  acquisition  process  is  only  an 
enabler.  In  other  words,  a  new  acquisition  process  alone  will  not  result  in  success 
if  matters  involving  acquisition  expertise,  leadership,  and  management  (including 
change  management)  are  not  appropriately  addressed.  Without  this  crucial 
element,  any  new  process  proposed  will  potentially  meet  resistance  and  failure. 

As  discussed  in  Chapter  II,  workforce  problems  involve  a  lack  of 
appropriately  trained,  educated,  and  experienced  acquisition  personnel  along 
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with  a  bureaucratic  and  cumbersome  acquisition  process.  Also,  stability  in 
leadership,  both  civilian  and  military,  remains  an  issue.  For  example,  a  2013 
GAO  study  reported  that  an  Air  Force  program  experienced  unstable  leadership 
due  to  having  four  different  program  managers  within  a  4-year  period  (GAO, 
2013).  Additionally,  there  is  a  growing  concern  due  to  budget  cuts,  hiring  freezes, 
sequestration,  and  commercial  sector  competition  that  the  DoD  will  not  be  able  to 
hire  and  maintain  highly  qualified  and  experienced  IT  acquisition  personnel.  For 
example,  in  a  2013  HASC  hearing  on  IT,  General  Keith  B.  Alexander, 
commander  of  United  States  Cyber  Command,  stated: 

The  issue  is  they  [the  acquisition  workforce]  have  taken  a  pay  cut 
and  now  we  are  saying,  “Well,  you  might  get  a  pay  cut  again  and 
this  pay  cut  will  be  furlough  and  we  are  not  sure  how  that  is  going 
to  go,  or  where  that  is  going  to  be.”  That  uncertainty  is  something 
that  truly  complicates  their  willingness  to  stay  with  us  [DOD]... these 
are  technically  qualified  people.  You  go  out  to  Google,  they  are 
looking  for  people  today.  You  know,  I  sat  down  with  the  Google  HR 
[human  relations]  folks.  They  said,  “Look,  we  are  paying,  you  know, 
probably  twice  as  much  as  you  are  paying  folks”  and  they  are 
having  trouble  getting  them.  (Information  Technology  and  Cyber 
Operations,  2013) 

Although  workforce  issues  have  not  been  directly  addressed  in 
acquisition  process  improvements,  there  have  been  recent  initiatives  that  have 
systematically  addressed  workforce  concerns.  First,  former  DoD  CIO  Vivek 
Kundra’s  25  Point  Implementation  Plan  to  Reform  Federal  Information 
Technology  Management  highlighted  the  role  of  the  IT  acquisition  workforce, 
created  focus  on  IT  acquisition  specialists,  and  helped  in  the  creation  of  a  new 
occupational  category  termed  the  “IT  Program  Manager”  (Kundra,  2010). 
Second,  the  current  DoD  CIO,  Teresa  Takai,  who  is  the  IT  acquisition  workforce 
Functional  Leader  (ITFL),  is  now  directly  responsible  for  the  IT  acquisition 
workforce  and  in  2012  she  issued  the  IT  Acquisition  Workforce  Strategic  Plan. 
This  plan  implements  near-term  initiatives  and  plans  for  longer-term  objectives 
associated  with  DoD's  IT  Acquisition  reform  movement  (Takai,  2012).  Specific 
actions  within  this  plan  can  be  summarized  under  four  guiding  strategic  goals: 
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•  Create  robust,  sustainable  IT  acquisition  and  IT  program 
management  communities. 

•  Develop  a  competency  model  and  career  roadmaps  for  IT 
acquisition  and  IT  program  management  personnel. 

•  Sustain  learning  and  growth  throughout  the  professional  lifecycle. 

•  Work  across  broad  stakeholder  communities  to  integrate  IT 
acquisition  reforms  into  IT  acquisition  curricula.  (Takai,  2012) 

Since  2012,  the  ITFL  has  been  engaged  in  improvement  efforts 
with  a  preliminary  focus  on  what  is  considered  to  be  the  "ABC's"  of 
improvements:  analysis  of  the  existing  state  of  the  IT  acquisition  workforce; 
building  the  IT  Functional  Integrated  Process  Team  (FIPT),  and  initiating  a  full- 
scale  competencies  review  (Takai,  2012).  The  ITFL  improvement  efforts  are 
ongoing  and  are  potentially  promising.  In  particular,  issues  of  tenure  and  rotation 
of  key  acquisition  personnel  are  discussed  in  the  plan;  however,  it  does  not  go  as 
far  to  set  policy  or  recommend  actions  as  it  relates  to  tenure  and  rotation. 

Although  training  and  education  are  mentioned  in  the  IT  Acquisition 
Workforce  Strategic  Plan  and  are  very  important  to  the  acquisition  workforce, 
training  and  education  are  no  substitute  for  experience  in  successfully  managing 
acquisition  programs  of  increasing  complexity.  Thus,  acquisition  personnel,  to 
including  uniformed  personnel  in  certain  capacities  within  the  acquisition 
workforce,  need  a  robust  process  of  assigning  and  sustaining  these  key  positions 
for  the  long  term.  This  strategic  plan  strengthens  and  broadens  those  initiatives, 
but  it  falls  short  in  resolving  program  instability  and  maintaining  an  experienced 
acquisition  workforce.  Also,  the  plan  fails  to  provide  change  management 
direction  for  the  workforce.  Along  with  experience  and  good  management,  there 
needs  to  be  change  management  initiative. 
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e.  Organizational  Change  Management 

One  final  aspect  of  IT  acquisition  reform  as  it  relates  to  a  new 
acquisition  process  and  the  workforce  involves  organizational  change 
management.  No  plan  or  solution  proposed  discussed  a  change  management 
process  or  how  the  DoD  will  go  about  executing  transformation  to  implement  a 
new  IT  acquisition  process.  Change  management  is  of  such  great  importance 
that  if  not  done  successfully  it  is  highly  likely  that  the  result  will  be  a  failure  to 
implement  the  necessary  changes  in  order  to  affect  timely  IT  acquisition.  As  it 
relates  to  the  acquisition  process  and  the  workforce,  there  needs  to  be  an 
imperative  to  implement  a  change  management  plan  that  would  facilitate  the 
implementation  of  any  new  acquisition  process  as  well  as  IT  workforce  change 
initiatives  found  in  the  workforce  strategic  plan. 

Given  the  size  and  complexity  of  the  DoD,  accomplishing  change 
can  be  a  very  difficult  undertaking,  which  is  why  effective  change  management  is 
necessary.  One  of  the  most  difficult  aspects  of  change  in  implementing  a  new 
acquisition  process  is  changing  the  culture  because  the  workforce  has  become 
very  accustomed  to  using  the  ineffective  but  well  understood  traditional 
acquisition  system  (Gilligan  et  al. ,  2009).  In  Leading  Change:  Why 

Transformation  Efforts  Fail,  John  P.  Kotter  (1996)  postulated  what  he  considered 
to  be  the  primary  reasons  why  change  efforts  fail.  Kotter  offered  eight  reasons 
why  this  failure  occurs: 

•  Not  establishing  a  great  enough  sense  of  urgency 

•  Not  creating  a  powerful  enough  guiding  coalition 

•  Lacking  a  vision 

•  Under  communicating  the  vision  by  a  factor  of  ten 

•  Not  removing  obstacles  to  the  new  vision 

•  Not  systematically  planning  for  and  creating  short-term  wins 

•  Declaring  victory  too  soon 

•  Not  anchoring  changes  in  the  corporation’s  culture  (Kotter,  1996) 
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Of  these  eight  reasons,  the  DoD  has  fallen  short  in  at  least  two 
areas:  not  removing  obstacles  to  the  new  vision  (e.g.,  removing  funding  issues) 
and  not  anchoring  change  in  the  corporation’s  culture  or,  in  the  DoD’s  case,  the 
organization’s  culture.  In  regard  to  culture  change,  and  closely  related  to  Kotter’s 
postulates,  there  is  the  seminal  work  of  Edgar  H.  Schein  in  his  1992  publication 
Organizational  Culture  and  Leadership.  In  reference  to  organizational  culture, 
Schein  (1992)  emphasized  that  behavioral  or  culture  change  is  important  to 
successful  transformation  (Schein,  1992).  As  described  by  the  National  Research 
Council  (NRC)  in  Achieving  Effective  Acquisition  of  Information  Technology  in  the 
Department  of  Defense: 

Cultural  aspects  of  the  DOD  acquisition  process  that  have  an 
impact  on  the  potential  success  of  IT  acquisition  efforts  include  the 
following:  the  bias  that  larger  is  better,  the  sense  that  oversight 
personnel  have  no  accountability  for  delaying  needed  IT 
capabilities,  an  emphasis  on  process  risk  (executing  the  acquisition 
process  correctly)  rather  than  on  the  risk  of  late  delivery  of  end-user 
capability,  an  unwillingness  to  admit  program  failure,  an  emphasis 
on  process  over  product,  a  belief  that  the  DOD  is  genuinely  unique, 
and  the  belief  that  what  is  good  for  large  weapons  systems  should 
be  good  enough  for  IT  systems.  (NRC,  2010) 

It  is  clear  that  a  culture  change  is  necessary  to  usher  in  the  sort  of  wide-ranging 
changes  proposed  by  any  new  acquisition  process.  Both  Kotter’s  and  Schein’s 
works  provide  a  framework  for  assessing  whether  the  DoD’s  current  IT 
acquisition  reforms  will  be  successful  and  by  all  accounts  at  this  point,  success  is 
uncertain.  To  provide  more  certainty,  effective  acquisition  leadership  and 
management  to  include  change  management  is  absolutely  essential.  According 
to  Allen  and  Eide  (2012),  “the  prognosis  for  effective  reform  is  dim  without 
embedding  leadership  actions  and  institutional  processes  that  will  drive  change 
in  the  culture  of  Defense  acquisition.  Without  such  intentionality,  one  can  expect 
to  repeat  the  history  of  unfulfilled  mandates  for  reform”  (Allen  &  Eide,  2012). 
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B.  SUMMARY,  FINDINGS,  RECOMMENDATIONS,  AND  FUTURE  WORK 

1.  Summary 

Information  technology  (IT)  has  become  ubiquitous  and  absolutely 
essential  to  the  DoD  and  to  United  States  national  defense.  Concepts  and 
strategies  such  as  network-centric  operations,  information  superiority  or 
dominance,  and  cyber  security  are  integral  to  the  DoD’s  ability  to  conduct  warfare 
in  the  twenty-first  century.  Furthermore,  the  DoD’s  reliance  on  IT  will  only 
increase  in  the  coming  years  and  will  continue  to  be  driven  by  innovation  and 
technological  advancements.  For  these  reasons,  it  is  important  for  the  DoD  to 
resolve  its  IT  acquisition  issues. 

The  traditional  Defense  acquisition  system  has  failed  in  meeting  IT  goals 
in  producing  new  technologies  that  conform  to  desired  cost,  schedule,  and 
performance  parameters.  This  study  focused  on  the  timeliness  or  scheduling 
portion  of  the  IT  acquisition  process,  although  cost  and  performance  are 
important  factors  that  are  influenced  by  schedule.  Many  government  reports, 
congressional  documents,  academic  papers,  and  other  writings  have  concluded 
that  the  traditional  acquisition  process  is  ill-suited  to  efficiently  deliver  IT  systems 
in  a  timely  manner.  This  literature  cited  numerous  IT  acquisition  deficiencies  with 
regard  to  process,  system  or  product  development,  workforce,  and  management 
of  IT  projects.  Currently,  improvements  to  the  IT  acquisition  process  are  being 
made  as  part  of  an  ongoing  revision  to  DoD’s  5000  series  acquisition  directives 
and  the  implementation  of  the  BCL  framework  for  Defense  business  systems. 

With  the  initiation  of  the  BCL  framework  in  June  2011,  the  DoD  has 
articulated  its  commitment  to  improving  the  acquisition  process;  however, 
implementation  of  BCL  has  been  slow  and  uneventful  thus  far.  Also,  it  is  too  early 
to  determine  if  this  latest  reform  effort  will  yield  significant  improvements  in  the 
speed  and  effectiveness  of  IT  acquisition.  Ultimately,  the  BCL  effort  may  join  a 
long  line  of  acquisition  reform  efforts  that  have  taken  place  over  the  past  three 
decades  in  which  many  of  these  reform  efforts  have  lead  to  even  more  reform. 
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This  may  occur  because  the  BCL  framework  contains  shortfalls  and  problems 
that  will  require  further  reform  or  tailoring.  Although  the  BCL  framework  has 
potential  benefits  and  confidence  is  high  that  it  is  the  long-awaited  solution  to  the 
DoD’s  acquisition  concerns,  there  is  no  data  that  can  ensure  optimism  going 
forward.  However,  data  does  exist  that  suggests  BCL,  as  well  as  any  other 
proposed  IT  acquisition  strategy,  will  continue  to  face  problems.  For  instance,  the 
BCL  process  maintains  similarities  to  the  traditional  system  in  terms  of  process. 
Also,  the  process  can  take  up  to  5  years  to  develop  an  IT  system  to  initial 
operating  capability  (IOC),  which  is  a  long  time  for  an  IT  project  to  reach  this 
point  as  compared  to  the  commercial  industry. 

Although  the  BCL  process  has  replaced  the  traditional  acquisition  system 
for  Defense  business  systems,  there  is  much  more  work  to  be  done  due  to 
lingering  issues  carried  over  from  the  traditional  acquisition  system.  These  issues 
involve  achieving  commercial  industry  best  practices,  which  is  a  challenge  given 
the  DoD’s  bureaucracy,  regulatory  procedures  and  statutes.  Also,  the  IT 
acquisition  funding  process  is  not  aligned  to  support  agile  acquisition  methods 
and  potential  Defense  spending  cuts  will  only  exacerbate  this  issue.  Most 
importantly,  the  acquisition  workforce  and  management  of  the  acquisition 
process  (e.g.,  MAIS  reporting  thresholds,  designated  DoD  authorities,  and 
change  management  efforts)  need  to  be  further  addressed.  The  next  two 
sections  present  a  list  of  findings  and  recommendations  based  on  this  study. 

2.  Findings 

•  Finding  1:  Different  IT  acquisitions  (i.e.,  hardware  or  software)  have 
inherently  different  acquisition  process  needs  and  thus  necessitate 
different  approaches  or  strategies  to  better  accommodate  timely 
acquisition.  Essentially,  the  BCL  framework  may  run  the  risk  of 
going  back  to  the  one-size-fits-all  approach  if  different  processes  or 
templates  are  not  designated. 
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•  Finding  2:  Challenges  and  barriers  to  timely  IT  acquisition  remain, 
which  include  achieving  commercial  best  practices,  Defense 
spending  cuts,  IT  funding  methods,  and  workforce  and 
management  issues.  Barriers  to  the  implementation  of  a  new 
acquisition  process  involve  issues  within  research  and  development 
reporting,  MAIS  reporting  thresholds,  designated  DoD  authorities, 
and  specified  appropriations. 

•  Finding  3:  The  BCL  framework  has  shortfalls,  inherent  weaknesses, 
and  potential  problems  involving  its  similarities  to  the  traditional 
acquisition  process,  limited  applicability,  and  process  timelines. 

•  Finding  4:  Funding  processes  remain  a  root  issue  for  BCL  that  will 
limit  its  effectiveness.  Also,  there  exists  a  dilemma  between  cutting 
cost  and  acquiring  IT  systems  through  agile  means.  No  proposed 
solution,  (i.e.,  BCL  or  IT  360)  will  be  unaffected  by  shrinking 
Defense  budgets  and  the  DoD  concept  of  “doing  more  without 
more.” 

•  Finding  5:  The  DoD  is  likely  to  experience  problems  in  full-scale 
implementation  of  the  BCL  process  with  its  planned  shorter 
durations  and  agile  intent  due  to  cultural  comfort  with  IT  projects 
taking  multiple  years  along  with  the  common  practice  of  thorough 
implementation  of  DoD  5000  process  steps.  Essentially,  these 
steps  can  negatively  influence  acquisition  programs  and  cause 
them  to  lean  towards  larger  increments  and  less  timely  delivery. 

•  Finding  6:  IT  acquisition  contracting  procedures  are  not  aligned  with 
the  objective  of  12-month  incremental  deliveries,  as  outlined  by 
BCL  guidance  and  thus  can  serve  to  increase  timelines. 

3.  Recommendations 

•  Recommendation  1 :  As  was  suggested  in  the  BCL  implementation 
guidance,  tailoring  of  the  BCL  framework  is  welcomed.  Due  to 
shortfalls  and  potential  problems  identified  within  the  BCL 
framework,  tailoring  should  account  for  the  different  strategies 
needed  to  address  the  different  needs  of  both  hardware  and 
software  development  projects  which  can  potentially  serve  to 
expedite  the  IT  acquisition  process.  Aspects  of  IT  360,  along  with 
the  concepts  of  process  templates  and  shorter  timelines  from  other 
process  models  or  frameworks,  should  be  incorporated  into  BCL. 
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•  Recommendation  2:  The  DoD  must  submit  to  Congress  a  proposal 
for  changes  to  be  made  to  the  PPBE  funding  mechanism  to  make 
the  IT  funding  process  more  flexible  and  adaptable  to  meet  the 
requirements  of  different  IT  acquisition  programs.  Furthermore,  it  is 
recommended  that  IT  funding  be  aligned  to  meeting  portfolio 
management  efforts  or  allocated  to  mission  areas  rather  than 
specific  programs.  Essentially,  more  stable  funding  to  ensure 
efficiency  and  sustainability  is  highly  recommended. 

•  Recommendation  3:  The  DoD  recently  established  annual  reporting 
on  Defense  Acquisition  (e.g.,  programs,  institutions,  workforce, 
managers,  executives,  and  industrial  partners)  with  its  first  report 
released  in  June  2013,  which  focused  primarily  on  performance 
related  to  Major  Defense  Acquisition  Programs  (MDAP).  Due  to  the 
need  of  progress  data  or  measures  of  effectiveness  on  the  BCL 
acquisition  process,  it  is  recommended  that  the  next  DoD  annual 
report  on  the  performance  of  the  Defense  acquisition  system  focus 
exclusively  on  the  BCL  process.  This  data  and  analysis  could  then 
be  used  to  measure  performance  to  inform  future  decisions  on 
programs,  policies,  processes,  or  recommend  further  tailoring. 

•  Recommendation  4:  Along  the  same  lines  as  Recommendation  3  in 
regard  to  assessment,  it  is  recommended  that  the  DoD  evaluate 
appropriate  metrics  for  BCL  progress  reporting  in  an  effort  to  fine- 
tune  the  process  using  lessons  learned  from  the  initial 
implementations. 

•  Recommendation  5:  It  is  recommended  that  DoD  programs  that 
require  rapid  acquisition,  particularly  those  involved  with  cyber 
security,  work  to  ensure  stable  sources  of  funding.  In  the  interim,  it 
is  recommended  that  the  DoD  explore  all  available  funding  options 
to  include  rapid  contracting  options. 

•  Recommendation  6:  Because  agile  acquisition  reflects  such  a 
significant  departure  from  past  IT  acquisition  processes,  it  is 
recommended  that  training  of  both  government  and  industry 
personnel  be  given  a  higher  priority  with  an  emphasis  on  culture 
and  organizational  change  for  government  employees.  Additionally, 
it  is  recommended  that  a  change  management  plan  be  executed 
simultaneously  with  BCL  implementation  and  that  this  plan  be 
incorporated  in  the  updated  version  of  DoDI  5000.02. 
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•  Recommendation  7:  Effective  IT  acquisition  process 
implementation  management,  change  management,  and  overall 
acquisition  system  management  are  key.  Therefore,  it  is 
recommended  that  the  DoD  focus  on  the  IT  acquisition  workforce 
and  its  management  of  the  IT  acquisition  system. 

•  Recommendation  8:  It  is  recommended  that  the  DoD  mandate 
fielding  of  IT  projects  at  the  same  pace  or  near  same  pace  as  the 
commercial  industry  with  a  penalty  of  project  cancellation  to  provide 
the  incentive  to  overcome  resistance  to  change  and  other 
problems.  This  mandate  can  also  serve  to  align  other  critical 
processes  (i.e.  oversight,  development,  testing,  and  contracting)  in 
order  to  ensure  that  they  function  on  the  same  expedited  timeline. 

•  Recommendation  9:  Given  all  the  IT  acquisition  change  proposals 
over  the  past  several  years,  it  is  recommended  that  the  DoD  focus 
its  efforts  on  the  barriers  and  challenges  to  any  new  process 
tailored  for  IT  acquisition  and  prioritize  reform  efforts  to  quickly 
implement  changes.  In  particular,  it  is  recommended  that  the  DoD 
initially  focuses  on  three  actions:  1)  the  mandate  that  IT  projects 
deliver  usable  capability  in  durations — shorter  than  what  is 
proposed  in  BCL  (i.e.,  6  to  12  months);  2)  submit  funding  change 
proposals  to  Congress  and,  in  the  interim,  the  DoD  should  adapt 
contracting  processes  to  make  them  more  agile;  and  3)  incorporate 
acquisition  templates  into  the  BCL  framework  in  order  to  expedite 
the  process. 

4.  Future  Work 

Future  work  and  research  within  the  area  of  IT  acquisition  should  consist 
of  the  following  activities: 

•  Conduct  an  assessment  of  the  feasibility  to  tailor  the  BCL 
framework  to  incorporate  process  templates  to  account  for  different 
types  of  IT  acquisition  processes 

•  Adapt  BCL  to  meet  the  needs  of  all  IT  acquisition  programs  (e.g., 
National  Security  Systems,  and  Warfighting  Systems),  not  just 
Defense  business  systems 

•  Develop  a  change  management  plan  for  the  new  acquisition 
process 
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•  Conduct  an  analysis  of  the  programs  currently  using  the  BCL 
framework  to  gain  insights  into  the  underlying  effects  of  BCL 
process;  doing  so  will  inform  better  policy  and  programmatic 
decisions. 

C.  CONCLUSION 

As  the  DoD  continues  its  efforts  at  transformation  of  its  military  forces  and 
Defense  business  systems  in  order  to  meet  the  various  challenges  of  twenty-first 
century  warfare,  it  will  increasingly  rely  on  IT  systems,  despite  budget  cuts.  Thus, 
DoD  will  need  to  resolve  its  IT  acquisition  issues  in  order  to  provide  systems  in  a 
timely  manner  that  meet  requirements  and  are  within  budget.  The  DoD  has 
introduced  a  number  of  initiatives  in  the  last  decade  in  an  effort  to  improve  IT 
acquisition;  however,  problems  remain.  BCL,  despite  having  many  potential 
benefits,  does  not  go  far  enough  to  address  the  underlying  conditions  and 
obstacles  discussed  throughout  this  study.  Improvements  to  requirements 
gathering  and  oversight  have  seemingly  been  addressed  in  the  BCL  framework 
although  issues  involving  the  acquisition  workforce,  acquisition  management  (i.e. 
change  management),  and  allocation  of  funding  continue  to  persist.  Most 
importantly,  how  can  any  program  succeed  that  can  take  up  to  5  years  to 
complete?  With  an  18-month  technology  change  cycle  in  the  commercial  sector, 
lengths  of  time  such  as  this  significantly  reduce  the  potential  for  the  successful 
implementation  of  an  information  system  that  will  meet  end-user  requirements. 

Despite  the  current  implementation  of  a  comprehensive  restructuring  of 
DoD  IT  acquisition,  the  process  is  not  entirely  fixed.  Given  the  current  DoD 
budgetary  environment  and  the  increased  pressure  to  reduce  Defense  spending, 
the  DoD  must  find  a  way  to  continue  to  improve  the  efficiency  with  which  it 
develops,  acquires,  and  fields  IT  systems.  There  is  no  silver  bullet  to  fixing  IT 
acquisition,  as  the  proposed  recommendations  within  this  study  are  only  ideas; 
however,  effective  management  up  and  down  the  chain  has  to  be  a  focal  point. 
Acquisition  personnel,  both  civilian  and  uniform,  are  the  drivers  of  success;  the 
acquisition  process  is  only  an  enabler  but  the  process  has  to  be  accommodating 
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to  timely  acquisition.  Addressing  funding  impediments,  installing  effective 
acquisition  management,  and  incorporating  aspects  from  other  frameworks  (e.g., 
templates  and  associated  timelines)  into  the  BCL  framework  along  with  an 
organizational  change  management  plan,  can  have  a  positive  impact  on  the 
speed  and  effectiveness  of  IT  acquisition  within  the  DoD. 

There  is  no  claim  that  all  the  findings  and  recommendations  presented 
here  are  entirely  new  ideas;  however,  they  provide  new  focus  in  addressing  this 
matter.  The  bottom  line  is  that  the  inability  to  effectively  acquire  IT  systems  in  a 
timely  manner  is  detrimental  to  national  defense.  These  problems  must  be 
overcome  because  IT  is  critical  to  DoD’s  capabilities  for  they  provide  command 
and  control,  decision  support,  and  overall  situational  awareness.  The  challenges 
surrounding  IT  acquisition  must  be  addressed  systematically  in  order  to  improve 
the  acquisition  process.  As  mentioned  in  the  Defense  Science  Board  2009 
report,  “without  an  acquisition  process  that  accommodates,  and  takes  advantage 
of,  IT’s  rapid  pace  of  change,  future  DoD  acquisition  officials  will  likely  be 
frustrated  in  their  efforts  to  equip  the  nation’s  warfighters  and  weapons  systems 
with  the  needed  information  technologies”  (DSB,  2009).  DoD  needs  to  focus  its 
efforts  by  mandating  that  IT  projects  deliver  usable  capability  in  shorter  durations 
(e.g.,  6-12  months)  by  modifying  the  BCL  process  to  include  acquisition 
templates  and  their  associated  timelines;  fixing  the  funding  process  to  make  it 
more  agile;  and  improving  acquisition  workforce  and  overall  acquisition 
management.  Doing  so,  will  increase  the  DoD’s  likelihood  of  delivering  IT 
capabilities  expeditiously. 
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